This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strnlen, strict ansi, newlib vs glibc

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__).
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
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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]