Subj : Re: Any help on why?
To   : borland.public.cpp.borlandcpp
From : Bob Gonder
Date : Wed Jul 07 2004 12:15 pm

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.

.