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

[Jan-Benedict Glaw]

On Thu, 2007-06-07 12:06:58 -0400, Mike Frysinger <address@hidden> wrote:
> On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <address@hidden> wrote:
> > > If I read a stream of data (from a file, a network socket, etc.) which
> > > is supposed to contain valid floating-point data, it is reasonable for
> > > a program to print it.  Especially so if the printing I am doing is a
> >
> > Data you didn't compute yourself isn't supposed to contain anything
> > known. Each and every bit may contain something you didn't expect,
> > that's why you have to do input checking.
> 
> yes, but the question is where do the robustness checks live ... every single 
> application out there or glibc ?  consider a game transmitting/receiving 
> floating point data over the network and logging the results ... should the 
> game assume that the library isnt going to crash when feeding values into 
> printf() or need it check every value itself ?

There's a difference in

        void send_float (float foo, int fd) {
                write (fd, &foo, sizeof (float));
        }

and

        void send_float (float foo, int fd) {
                char buf[100];
                snprintf (buf, sizeof (buf), "%f", foo);
                write (fd, buf, strlen (buf));
        }

The second variant surely burns more CPU cycles, even on both sides,
but it'll easily work even for different architectures. (I just think
about VAX where the CPU FP support is made up of four non-IEEE float
types...)

So yes, I'd expect every application getting traffic from a
non-controlled source to check its input.  The CPU shouldn't produce
values like these, ever, and printf() should be capable of printing
anything that the CPU generates natively.

MfG, JBG

-- 
      Jan-Benedict Glaw      address@hidden              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :

signature.asc
Description: Digital signature