Re: glibc segfault on "special" long double values is _ok_!?

[Nix]

On 8 Jun 2007, Jan-Benedict Glaw stated:
> On Fri, 2007-06-08 00:14:34 +0100, Nix <address@hidden> wrote:
>> It's somewhat unusual for applications to accept double-format data over
>> the network or from files; but modulo byte-swapping, has anyone *ever*
>> seen an application that checks to be sure that the data it's received
>> is a valid IEEE754 floating-point number? I've never seen any such app,
>> I've never heard of anyone taking precautions under the assumption that
>> a double with a one-bit error (I think it's one bit, I've lost the start
>> of this thread) may cause core dumps if printed, and I've never
>> considered doing any such thing myself. It's generally assumed that
>> printing doubles is safe, no matter their origin.
>
> FWIW, I haven't seen apps that shift binary data around all that much,
> at least not anything more complicated than integers of known size.

Yes, it's rare.

> For anything more complicated, I'd always create an easy to transmit
> representation, even if that costs some CPU cycles.

So would I, but this is old and stable code we're talking about. (I'd guess
most code that does anything like writing doubles to disk is aged.)

>> I just checked with a bunch of numerics people in the office (they're in
>> financials so they're mostly contemputous of IEEE floating point types
>> but use them sometimes anyway) and every one expressed astonishment that
>> printing random bit patterns and pretending they are doubles could cause
>> crashes. Phrases like `oh shit we don't handle that, can it really
>> happen' were used: these guys write stuff that billions of dollars of
>> transactions rides on top of on a daily basis (and yes, these apps use
>> glibc, and yes, they snprintf() doubles at times, mostly for debugging's
>> sake: SIGSEGV is mostly trapped while that's done, but still).
>
> They should play with more different types of computers and
> architectures for sure. Once you've learned that exchanging data is
> error-prone, you think twice for every bit exchanged :)

They're doing short-term serialization of data into blobs in relational
databases: they only care that it comes back out OK on the same physical
machine. But we've *seen* hardware faults flip single bits in those
databases, and we kind of assumed that we could at least do debugging
printouts saying `argh, probable corruption, here's what we got'. Now it
turns out we can't.

> Even more important, I think this "bug" would be fixed if the IA64
> CPUs could actually create these invalid long doubles during regular
> computation. But they cannot. So it's not a bug.

True.

-- 
`... in the sense that dragons logically follow evolution so they would
 be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
 furiously