This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: CompactFlash Disk Geometry
- From: "Jeff Baker" <jbaker at qnx dot com>
- To: "Max Bowsher" <maxb at ukf dot net>,<cygwin at cygwin dot com>
- Date: Tue, 22 Apr 2003 13:25:29 -0400
- Subject: Re: CompactFlash Disk Geometry
- References: <003d01c308ed$07e6e670$78d96f83@pomello>
I wouldn't expect to see it print a full 64 bit integer, but I was wondering
why it's pushing the rest of the data out of place.
VC: 15680 1 1 512
Cygwin: 15680 0 1 1
If it was merely a problem with printing the 64 bit argument then shouldn't
that be the only one that's mangled in the output? In this data '15680' is
coming from the LARGE_INTEGER but I don't know where the zero is coming
from, or why the last element goes from 512 to 1, or where the 512 vanishes
to.
> Jeff Baker wrote:
> > Ok so allow me to correct myself here. The 'Cylinders' element in the
> > DISK_GEOMETRY structure is a LARGE_INTEGER, which isn't being printed
> by a
> > simple printf("%d"). If I print the Cylinders.LowPart element the
> output
> is
> > correct. Since trying to printf a LARGE_INTEGER works on both Visual
> C
> and
> > a version of Watcom I have, is this a bug in Cygwin?
>
> Why would you expect %d to print a LARGE_INTEGER? I suspect that your
> Visual
> C and Watcom programs will give incorrect output for values larger than
> 2^31.
>
> Printing 64-bit ints is rather nonstandard, unfortunately.
>
> For MSVCRT, I guess (untested) you would need %I64d.
> For newlib (Cygwin), you will need %lld or %qd.
>
>
>
> Max.
>
--
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/