apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rainer M. Canavan" <...@canavan.de>
Subject Re[2]: IRIX errno for apr_stroff, apr_atoi64
Date Fri, 16 Oct 2015 23:45:02 GMT
William A Rowe Jr <wrowe@rowe-clan.net> wrote:
> Any chance you could review the man page of these functions on IRIX and
> report back, specifically return value and error exceptions?  MAX is a
> valid value.  They might be playing some game with endptr to signify errors.

There's no hint to such a behaviour in the manpage (available 
online e.g. at http://irix.polarhome.com/service/man/?qf=strtoull&tf=2&of=IRIX&sf=3
),
and my experiments would indicate that the endptr just doesn't care
about numeric overflows and happily points at the character following
100 or more '9's.

It turns out that it is indeed pthread's fault, and errno behaves
properly if one either #include <pthread.h> as well whenever <errno.h> 
is used, or alternatively, errno.h can be persuaded to use the thread-safe
definition of errno by defining _SGI_MP_SOURCE,  _POSIX_C_SOURCE >= 199506L
or _XOPEN_SOURCE >= 500. I haven't tested any of those with apr yet, 
just with a small test program.

rainer
 

> On Oct 14, 2015 18:17, "Rainer M. Canavan" <apr@canavan.de> wrote:
> 
> > Hi,
> >
> > it appears that teststr has 2 failures on IRIX since quite a while -
> > at least since 1.4.2:
> >
> > teststr             : \Line 259: for '123545': errno was 89 not 0
> > |Line 285: strtoff failed for 1234
> > FAILED 2 of 13
> > Failed Tests            Total   Fail    Failed %
> > ===================================================
> > teststr                    13      2     15.38%
> >
> > I'm not sure where the 89 comes from - that would be ENOSYS, and that
> > doesn't happen in a simple test program that only uses apr_strtoff()
> > or apr_strtoi64(). If my tests are correct, the IRIX libc takes a
> > liberal approach to setting errno, i.e. the value is only relevant if
> > and only if the correct value is outside the range of representable
> > values - which is permissible accoring to my reading of the C11
> > standard.
> >
> > Once apr_stroff() has failed, errno bounces back to the  previous value,
> > e.g. 34 (ERANGE) whenever strtoll() (or apr_stroff() or apr_strtoi64()
> > is called, even if it is reset to 0 before the call and all arguments
> > are valid.
> >
> > This behaviour is reproducable in a simple test program that only
> > uses strtoll() if the program is linked against libpthread.so.
> > The program below prints "errno: 34 off: 12345" as the last
> > line when linked against libpthread, and "errno: 0 off: 12345"
> > otherwise.
> >
> > The patch below fixes teststr on IRIX, but I'm not convinced
> > that it is actually correct.
> >
> > rainer
> >
> > --- ../../src/apr-1.5.2/strings/apr_strings.c   Thu Oct 15 00:52:54 CEST
> > 2015
> > +++ apr_strings.c       Thu Oct 15 01:12:16 CEST 2015
> > @@ -238,6 +238,7 @@
> >  {
> >      errno = 0;
> >      *offset = APR_OFF_T_STRFN(nptr, endptr, base);
> > +    if ((*offset != APR_INT64_MIN) && (*offset != APR_INT64_MAX)) return
> > APR_FROM_OS_ERROR(0);
> >      return APR_FROM_OS_ERROR(errno);
> >  }
> >
> > @@ -244,8 +245,11 @@
> >  APR_DECLARE(apr_int64_t) apr_strtoi64(const char *nptr, char **endptr,
> > int base)
> >  {
> >  #ifdef APR_INT64_STRFN
> > +    apr_int64_t i;
> >      errno = 0;
> > -    return APR_INT64_STRFN(nptr, endptr, base);
> > +    i = APR_INT64_STRFN(nptr, endptr, base);
> > +    if ((i != APR_INT64_MIN) && (i != APR_INT64_MAX)) errno = 0;
> > +    return i;
> >  #else
> >      const char *s;
> >      apr_int64_t acc;
> >
> 
> 

Mime
View raw message