Re: strnlen, strict ansi, newlib vs glibc

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

There were a couple of typos in the previous patch.  New one attached.

I am done for the week.

--joel
On 8/15/2014 9:23 AM, Joel Sherrill wrote:
> Attached is a new version of the patch. Comments interspersed.
>
> On 8/15/2014 6:52 AM, Corinna Vinschen wrote:
>> On Aug 14 17:53, Joel Sherrill wrote:
>>> This type of change is always tricky. FreeBSD's string.h only had
>>> __STRICT_ANSI__.  I read the glibc version and attempted to
>>> translate their feature flags into the BSD style ones we have
>>> from <sys/cdefs.h>.
>>>
>>> There are a few methods I have no idea how to guard:
>>>
>>> + The block of Windows strcmpi and friends at the bottom
>>> of the file.
>> Nuke them.  We don't have any Windows target, and Cygwin doesn't export
>> those.  They are likely a remnant from the time the Cygwin devs were
>> trying to make Cygwin a MSVCRT replacement (pre 1999).
> Done. :)
>>> + strlwr() and strupr(). No idea where those originated.
>> These ill-advised functions, which apparently predate any multibyte
>> concernes are actually in newlib.  They are ASCII only, non-standard,
>> and inherently broken by design.  So the question is, do we really want
>> to export them?  If so, maybe we should guard them with something like
>>
>>   #ifdef __USE_NONSTD
> That does not appear anywhere in the source. I hate to add a new guard.
> They are wrapped in !defined(__STRICT_ANSI__).
>
> I am at a loss to do more.
>>> + _strerror_r() is another unknown origination.
>> This is the REENT version of strerror_r, as you already commented in
>> your patch.  In theory, these functions are outside of any standard,
>> just by having the underscore prepended.  I don't think they need
>> any standards guard.
> OK. I dropped my comment in the file about not knowing what to do.
>>> Attached is try1. I expect there to be a few rounds of this.
>>> I did build a complete sparc-rtems toolset and all RTEMS tests.
>>>
>>> Please check what I did and offer corrections and improvements.
>>> I tried to not rearrange the file. There is likely opportunity to
>>> group methods with similar guards.
>> Other than the above, looks good except:
>>
>>> +#if (_XSI_VISIBLE - 0) >= 500
>> shouldn't be necessary.  If sys/cdefs.h is included, _XSI_VISIBLE
>> exists.
>>
>>    #if _XSI_VISIBLE >= 500
>>
>> should be sufficient.
> I fixed that pattern everywhere it occurred.
>> Thanks,
>> Corinna
>>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Attachment: string_h-v3.diff
Description: Text document