On Jul 28 10:28, Gedare Bloom wrote:
> On Fri, Jul 28, 2017 at 9:08 AM, Corinna Vinschen <vinschen@redhat.com> wrote:
> > On Jul 28 07:40, Gedare Bloom wrote:
> >> Corinna, good catch. I mentioned this issue to Joel but it dropped out
> >> the bottom some how. Is it only (for example) the strtoimax_l() that
> >> needs to be guarded, or also the _strtoimax_l? (I suspect only the
> >> strtoimax_l, but want to be clear before the next round of patches
> >> lands here.)
> >
> > The reentrant prototypes use locale_t, so they depend on including
> > xlocale.h, too.  It's a bit uncommon but the simplest solution.
> >
> Since the non-reentrant version (e.g., strtoimax) wraps the re-entrant
> one, then there is no support unless locale is available. Would it be
> better to have a non-reentrant, nonolocale implementation in tandem
> with the reentrant one, or do we not worry about it and don't support
> these functions at all unless the POSIX_SOURCE is set properly and
> BSD_VISIBLE?

Good catch on your side, I really had to look it up now.  Here's how it
is in the other, similar cases like strtol:

There are actually four functions:

  strtol
  strtol_l
  _strtol_r  
  _strtol_l

_strtol_l is the internal implementation and *static*.  _strtol_r
is the exported reentrant function and consequentially not having
the locale_t parameter.

So, why not just keep it at that for now with strtoimax, etc?  It only
requires minimal changes and nobody using the reentrant functions
actually asked for a reentrant function with thread-local locale
parameter yet :}

As a result, the guards for the exported reentrant functions are not
required.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat