strnlen, strict ansi, newlib vs glibc

[Corinna Vinschen]

On Aug 18 09:22, Joel Sherrill wrote:
> 
> 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. :)

Cygwin has a few places where these functions are still used.  Fortunately,
Cygwin has its own implementation of these functions (using WCHAR) so it
doesn't require the exports from newlib.

There are, however, two Cygwin tools using strlwr.  The *exported*
functions are the newlib versions, so they are in fact used.  I see to
it to drop these calls from the Cygwin tools in favor of a better
implementation, but still, we can't remove the exported entry points for
backward compat reasons.

But probably we should.  So what I'll do is this:  I change Cygwin to
export its own implementation of these functions.  Having done that,
we're free to nuke the newlib variants.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20140818/6f180f3d/attachment.sig>