This is the mail archive of the
mailing list for the newlib project.
Re: Remove strlwr and strupr
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: newlib at sourceware dot org
- Date: Fri, 22 Aug 2014 10:35:06 -0500
- Subject: Re: Remove strlwr and strupr
- Authentication-results: sourceware.org; auth=none
- References: <53F638F1 dot 6010402 at oarcorp dot com> <20140821205510 dot GG32314 at calimero dot vinschen dot de>
On 8/21/2014 3:55 PM, Corinna Vinschen wrote:
> Hi Joel,
> On Aug 21 13:22, Joel Sherrill wrote:
>> Attached is a patch to remove strlwr and strupr.
>> I manually edited the Makefile.in and would appreciate someone
>> comfortable with regenerating the Makefile.in and removing
>> the two files to do that once this is approved.
>> 2014-08-21 Joel Sherrill <email@example.com>
>> * libc/include/string.h: Remove strlwr() and strupr() prototypes.
>> * libc/string/Makefile.am: Remove strlwr.c and strupr.c.
>> * libc/string/Makefile.in: Regenerate.
>> * libc/string/strings.tex: Remove includes for strlwr() and strupr().
>> * libc/string/strlwr.c: Remove.
>> * libc/string/strupr.c: Remove.
> Uhm... I'm terribly sorry, but I had second thoughts about this issue.
> What about newlib users who already used these functions? While they
> are not in any standard and only work for ASCII, they are not exactly
> unknown. Try a simple search for strlwr on the net. It turns up lots
> of hits.
> Maybe it is better in terms of backward compatibility to keep the
> functions in and just disable them in the header, after all...?
I think we are seeing the same picture from different angles. They are
specific as best I can tell. Windows/Cygwin versus POSIX/Linux/BSD. The
I see are MSDN and QNX documentation. Then I see hits for people asking why
isn't this available on platform X.
glibc doesn't provide it.
FreeBSD libc (at least string.h) does not have it.
I think any code using it is non-portable and likely has a Windows
We have probably already spent more effort on this than the methods are
work but they inherently not POSIX and not on the free POSIX OSes.
Don't really care what the end result is. They aren't that big a deal. :)
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