On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> On Thu, 2007-06-07 12:06:58 -0400, Mike Frysinger <[EMAIL PROTECTED]> wrote:
> > On Thursday 07 June 2007, Jan-Benedict Glaw wrote:
> > > On Wed, 2007-06-06 22:44:17 +0100, James Youngman <[EMAIL PROTECTED]>
> > > 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.
