Re: [boost] [boost::endian] Request for comments/interest (floating point endian handling)

Subject: Re: [boost] [boost::endian] Request for comments/interest (floating point endian handling)
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-06-01 09:03:38

Cliff Green wrote:
> Tomas Puverle wrote:
>
> > > This is a good point.  And this is not as unusual as you
> > > may think, even on
> > > IEEE 754 machines.  For example, on some compilers on Intel
> > > machines,
> > > sizeof(long comes in at 12 bytes (even though long double
> > > is only 80 bits),
> > > essentially meaning that the last two bytes are garbage
> > > when the data is in memory.
> >
> > what would you suggest the endian should library do?
>
> I was mainly pointing out the function that Robert Stewart
> was proposing or using as an example:
>
> >   template <class T, class U>
> >   T
> >   big_endian_cast(U);
>
> I did the same thing many years ago (when writing an endian
> swapping utility), and noticed that when returning by value,
> the fp normalization would occur, causing silent "changing
> of the internal bits".  Floating point values could be
> "in-place" swapped, but this was the only safe usage (I.e.
> after the "in-place" swap, the values would have to be sent
> across the network or written to disk, etc). The brittleness
> with swapping fp values is a subtle and non-obvious problem.

I hadn't heard of this problem before, but I'm glad to know about it now.  Do you know whether zeroing the remaining bits solves the problem?  If so, specializing for FP versus integer types would allow handling the difference.

> The best endian solution would be one that includes safe and
> portable binary floating point approaches, although I'm not
> familiar enough with the possibilities to know how much
> effort that entails. At the least, any endian facilities
> need to either disallow or cause warnings to occur (really
> BIG and nasty warnings would be best), when used with fp
> values.

I agree that FP should be disabled if not supported correctly, but I'd rather find the correct solution and use it for FP types.

> I ended up writing endian facilities that were, in effect,
> "take this stream of bytes, and return a value correctly
> endian swapped (and safe) for use by the app". For example,
> the function above was something like:
>
> template <typename T>
> T extract_and swap_from_stream(const char*);
>
> It would be used as:
>
> val = extract_and_swap_from_stream<int32_t>(buf);

That's an interesting facility.  It could be built atop the approaches we've been discussing.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.