Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <422CDA77.2236DAA2@dessent.net>
Date: Mon, 07 Mar 2005 14:49:27 -0800
From: Brian Dessent <brian AT dessent DOT net>
Organization: My own little world...
MIME-Version: 1.0
To: "'Cygwin List'" <cygwin AT cygwin DOT com>
Subject: Re: types "quad_t" & "u_quad_t"
References: <422CCEE0 DOT 9070408 AT tlinx DOT org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Reply-To: cygwin AT cygwin DOT com

Linda W wrote:

> I was lamenting the lack of the simple "hexdump" facility
> I have on linux.  I figured -- how difficult would it be
> to port that.

Cygwin already has the 'od' utility (in coreutils) which has the same
functionality.  For example, "od -A x -v -t x1z filename" will give a
nice side-by-side hex/ascii output of a file.

> Well...not too, turns out, though, that it needs a type
> quad_t and u_quad_t defined.

As far as I know, and I could be wrong, the quad_t and u_quad_t types
are BSD-isms and not actually part of any standard.  POSIX defines
int64_t and u_int64_t which would be the more portable types for a
program to use.  'hexdump' is from BSD as well so that's probably why it
uses them and not the standard ones.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/