strnlen, strict ansi, newlib vs glibc

[Corinna Vinschen]

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

> + 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

> + _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.

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


Thanks,
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/20140815/0435c72a/attachment.sig>