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

[Mike Frysinger]

On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> 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...)

read what i said again ... the clients are doing write()/read() on the double 
directly, but one side has debugging enabled so it additionally does printf() 
on the values coming across -> bam, server crashes
-mike

signature.asc
Description: This is a digitally signed message part.