Re: New g_ascii_strtod/g_ascii_dtostr() patch

["Matthias Clasen" <matthiasc poet de>]

What glibc tries to do in cases like this is saving the old errno and
restoring the saved value
if no error occurred. I'm pretty sure it fails to do so in some cases, but
at least most of the
places in the glibc-2.2 sources where I see __set_errno (0) are like this:

  saved_errno = errno;
  __set_errno (0);
  syscall_that_may_set_errno ();
  if (!success)
    return;
  else
    __set_errno (saved_errno);
  /* continue to do things... */

Matthias

----- Original Message -----
From: "Alex Larsson" <alexl redhat com>
To: "Tim Janik" <timj gtk org>
Cc: "Gtk+ Developers" <gtk-devel-list gnome org>
Sent: Friday, October 05, 2001 5:38 PM
Subject: Re: New g_ascii_strtod/g_ascii_dtostr() patch


> On Fri, 5 Oct 2001, Tim Janik wrote:
>
> > On Fri, 5 Oct 2001, Alex Larsson wrote:
> >
> > > On Fri, 5 Oct 2001, Alex Larsson wrote:
> > >
> > > > On Fri, 5 Oct 2001, Tim Janik wrote:
> > > >
> > > > > On Thu, 4 Oct 2001, Alex Larsson wrote:
> > > > > > He proposed that we should set errno to 0 in g_ascii_strtod().
What do
> > > > > > people think about this? Personally i don't like doing magic
that makes
> > > > > > it behave in a way the standard call does.
> > > > >
> > > > > for g_ascii_strtod(), we're pretty free to reset errno to 0, since
> > > > > we're not 1:1 mimicking a libc function there.
> > > >
> > > > We are mimicking an "old" pre-locales libc function though.
> > >
> > > (responding to myself)
> > >
> > > Also, reseting errno here may cause problem for users that actually
want
> > > the errors in a function to "stick". If we randomly clear it people
may
> > > miss an old error.
> >
> > i'm pretty sure that:
> >
> > errno=42;
> > some_libc_function_that_doesnt_fail();
> > assert(errno==42);
> >
> > is _non_ portable. esp. since there're a bunch of libc
> > functions that call others and may workaround errnos in
> > such subcalls, simply by setting errno=0 at the end.
>
> Looking into this, I can see setting clearing errno could make sense.
>
> Normally, errno is only valid when a syscall returns an error (often -1).
> so you would never read it when it wasn't set by the syscall. strtod is a
> bit different though, in that on overflow it returns a valid number
> (+/- HUGE_VAL or 0), but then sets errno to ERANGE. I can easily see
> people forgetting to check the return value before checking
> errno.
>
> It even seems impossible to see the difference between return=0.0,
> errno=undefined (for "0.0") and return=0.0, errno=ERANGE (underflow)
> without clearing errno first.
>
> / Alex
>
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list