Re: Importing inttypes methods

[Gedare Bloom <gedare@rtems.org>]

On Fri, Jul 28, 2017 at 2:29 PM, Corinna Vinschen <vinschen@redhat.com> wrote:
> 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.
>
OK. Aditya please pursue this direction for implementation. It will
take a bit more refactoring to get it right.

>
> Corinna
>
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat