This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: strnlen, strict ansi, newlib vs glibc
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Craig Howland <howland at LGSInnovations dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Mon, 18 Aug 2014 09:22:16 -0500
- Subject: Re: strnlen, strict ansi, newlib vs glibc
- Authentication-results: sourceware.org; auth=none
- References: <53ECD579 dot 1030703 at oarcorp dot com> <53ECD62F dot 90204 at gentoo dot org> <def6c009-0c8b-4649-badb-356fe3bb59ec at email dot android dot com> <53ED3DF7 dot 4090307 at oarcorp dot com> <20140815115235 dot GB7766 at calimero dot vinschen dot de> <53EE17D3 dot 5040402 at oarcorp dot com> <20140815214622 dot GN28562 at calimero dot vinschen dot de> <53EE8387 dot 4000403 at LGSInnovations dot com>
On 8/15/2014 5:02 PM, Craig Howland wrote:
> On 08/15/2014 05:46 PM, Corinna Vinschen wrote:
>>>>> + 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 wanted to reiterate that this should be exactly how they were guarded
before.
I committed my patch for getting the guards improved. We can deal with
these two
methods as a separate patch.
>> OTOH, this makes them visible in all circumstances but -ansi.
>> I think we would really like to make them only visible if somebody
>> really wants newlib extensions.
>>
>> So what if we define _NEWLIB_SOURCE and __NEWLIB_VISIBLE for stuff
>> which is really newlib-only and not in any standard nor a Glibc
>> extension?
> If these really are ill-advised functions of unknown origins that are best
> wanted to go away, perhaps it should be something more like
> _BACKWARD_COMPATIBILITY_ONLY, or _NEWLIB_DEPRECATED (strlwr() more so thatn
> strupr()). That is, these appear to be a special sub-set of Newlib extension.
> Of course, the bad part about an idea like _NEWLIB_DEPRECATED is that a
> configure option would need to be added for it. But the good part is that it
> would provide an easy mechanism to hide some dead wood that's being kept purely
> for backwards compatibility purposes.
Over the weekend, I thought about this and wondered if it was just OK to
delete them.
Minimal nice is a nice post to newlib, Cygwin, and RTEMS mailing lists
saying these are being deleted and recommending how to fix the code.
That should
be enough for Google to find.
If Cygwin builds without them, then the the likelihood of their being
code that
uses them is small. And that part of the application is not portable and
wouldn't
compile on Linux. I say break the code and I don't say that often. :)
--joel
> Craig
--
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
- References:
- strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc
- Re: strnlen, strict ansi, newlib vs glibc