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