Importing inttypes methods

[Aditya Upadhyay]

I have declared all *_l methods within __BSD_VISIBLE guard in
inttypes.h. I am attaching the patches for rest of the inttypes
methods. Please review the same. Also i have tried to make the line
length < 80  in inttypes.h file.

Thanks & Regards,
Aditya

On Sat, Jul 29, 2017 at 7:27 PM, Aditya Upadhyay <aadit0402@gmail.com> wrote:
> Yes,
> I am following the direction.
>
> Regards.
> Aditya Upadhyay
>
> On Sat, Jul 29, 2017 at 6:10 PM, Gedare Bloom <gedare@rtems.org> wrote:
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Importing-strtoimax-inttypes-method-from-FreeBSD.patch
Type: text/x-patch
Size: 7405 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170730/53da49c7/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Importing-strtoumax-inttypes-method-from-FreeBSD.patch
Type: text/x-patch
Size: 6264 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170730/53da49c7/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Importing-wcstoimax-inttypes-method-from-FreeBSD.patch
Type: text/x-patch
Size: 6494 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170730/53da49c7/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Importing-wcstoumax-inttypes-method-from-FreeBSD.patch
Type: text/x-patch
Size: 6379 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20170730/53da49c7/attachment-0003.bin>