[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jan-Benedict Glaw
Subject: Re: glibc segfault on "special" long double values is _ok_!?
Date: Fri, 8 Jun 2007 01:22:55 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Fri, 2007-06-08 00:14:34 +0100, Nix <address@hidden> wrote:
> On 7 Jun 2007, Tor Myklebust outgrape:
> > And the second variant can segfault if you replace 'float' by 'long
> > double' (changing the format string appropriately) and you feed it
> > something bad.  Why is this a good thing?
> 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.

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

> 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 :)

Don't rely on data you cannot *fully* trust. In all other cases,
pretend that it's evil data and handle it like that.

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.


      Jan-Benedict Glaw      address@hidden              +49-172-7608481
Signature of:         "really soon now":      an unspecified period of time, 
likly to
the second  :                                 be greater than any reasonable 
                                              of "soon".

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]