Subj : Re: Any help on why?
To   : borland.public.cpp.borlandcpp
From : Stan DeGroff
Date : Fri Jul 09 2004 02:19 am

I did verify that %LX will correctly display a "double" float.  1.0 =
0x3FF0,0000,0000,0000.  Follow thread on down.  I used this code in another
post:
#include <stdio>
main()
{
float x;
float *ptr_x;
x = 1.0;
ptr_x = &x;
printf("%f = %LX\n %p, %p, %d\n", x, x, ptr_x, &x, sizeof x);
return 0;
}
 result :
doesn't seem to care if it's double or float. It always returns
0x3FF0,0000,0000,0000 = 1.0

I changed values to 2, 3, 4, 4.1 etc and it follows correctly except the
bits seem to always be 64 bit result.

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message
news:3icoe0hp1085khooponp86sv7b1qlb91km@4ax.com...
> Wayne A. King wrote:
>
> >On Wed, 07 Jul 2004 07:36:44 -0700, Bob Gonder
> >wrote:
> >
> >>What if you want to see how a float works?
> >
> >Then you dump it as raw bytes (chars),
>
> Yeah, you can do that too. But then you'd have endian issues as you
> pointed out.  The %LX seems to correct endianness.
>
> > not by using a type
> >specifier in a lib function which is intended for a different type.
>
> I don't really think it was inteded for any "type". It was intended to
> convert binary data (of the proper size) into hex.
>
> >The compiler implementors are allowed to assume that the
> >correct argument type will be passed.
>
> They are allowed to assume that the correct size data will be passed.
> What's in that data, they don't care about.
>
> > Since doubles and ints
> >are different sizes, and different internal layouts, passing doubles
> >where ints are expected can only lead to unpredictable behavior.
>
> I think it would be predictable. Perhaps surprising to the unwary, but
> predictable.
>
> >>%X takes BYTES off the stack and displays them. It doesn't care what
> >>type they were  before they got put on the stack.
> >
> >Where did you get that notion from? Show me where it says that in
> >the ISO/ANSI specs for the C/C++ Standard Libraries.
>
> Where else is it going to get it? From Space?
> It reads the Byte, Word, Dword, Qword (whatever the prefix calls for),
> from the stack and formats it in hex. What's so difficult to
> understand about that?
>
> >You're making assumptions about implementation details,
> >which may vary from compiler to compiler.
>
> I very much doubt %X is going to vary much. It's pretty cut-n-dried.
>
> > You're ignoring
> >the fact that C and C++ are languages which have extensive
> >formal specifications. The language specifies what is valid
> >or invalid.
>
> I don't recall seeing anything that said that you had to pass an INT
> and *nothing but* an INT to a %X.  Says it takes an int, but it
> doesn't say you can't use something else the size of an int.
>
> > You can't arbitrarily use standard library functions
> >in any way you want (and expect it to work consistently across
> >implementations/platforms.)
>
> Right, not when sizes are changing all the time. But that's a bug in
> the standard (some would call it a feature).
>
>
> >>Poster could have used %lX for float or double as %X is int, whatever
> >>size that is (target dependant)..
> >
> >When l (lower case L) is used with any of these:
> >d i o u x X
> >then arg is interpreted as a long int.
> >On the platform in question, a long int is 32-bits and a double is 64
bits.
>
> Right, should have been %LX
>
> So the OP's printf("%x %x", double1,double2) would have ignored the
> double2, printing the first 32bits (LSB) of double1 (which was zero),
> then the MSB 32 bits.  (Are you still reading, Stan?)
>
>
> >Further, since floats/doubles are stored with certain bits used for the
> >mantissa and certain others for the exponent,
>
> There's the words I was looking for! (Got them backwards too...)
>
> > whereas ints are stored
> >according to the endian architecture of the platform, interpreting a hex
> >dump of a float (mis)interpreted as an int (or vice versa) would be
> >challenging to say the least.
>
> I don't see why. Perhaps I'm wrong (again) but when a value is stored,
> be it short or long or float, isn't it stored in endian fashion? So a
> float or double will be pushed in endian fashion, and %X will read it
> in endian fashion, and display it MSB first.
>
> %X seems to take endian into account when converting. Needs to,
> doesn't it? I mean, if you take int i=0x1234 you don't want to see
> 3412 come out of %X.
>
>
>

.