On Fri, Oct 16, 2015 at 7:45 PM, Rainer M. Canavan <[email protected]> wrote:
> William A Rowe Jr <[email protected]> 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 > That's essentially like _REENTRANT on Solaris; I helped someone with their hopeless socket API code years ago and saw that they had inserted checks for all sorts of errno values they had seen in testing but it was never enough. (They weren't accessing the errno value for the thread.) Look in build/apr_hints.m4 for the proper place for such settings, including *-irix*) APR_ADDTO(CPPFLAGS, [-D_POSIX_THREAD_SAFE_FUNCTIONS]) > > > On Oct 14, 2015 18:17, "Rainer M. Canavan" <[email protected]> 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; > > > > > > > > -- Born in Roswell... married an alien... http://emptyhammock.com/
