Re: New g_ascii_strtod/g_ascii_dtostr() patch

[Alex Larsson <alexl redhat com>]

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