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 <vapier@gentoo.org> wrote:
> > On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <jay@gnu.org> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 827 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20070607/cd18f2a9/attachment.sig>