[PATCH v2] ctype: use less short names in public header

[Brian Inglis]

On 2021-11-12 03:27, Corinna Vinschen wrote:
> On Nov 11 17:28, Mike Frysinger wrote:
>> On 11 Nov 2021 11:35, Corinna Vinschen wrote:
>>> On Nov 10 20:37, Mike Frysinger wrote:
>>>> We're seeing a build failure in GNU sim code which is using _P locally
>>>> but the ctype.h define clashes with it.  Rename these to use the same
>>>> symbols that glibc does.  They're a bit more verbose, but seems likely
>>>> that we'll have fewer conflicts if glibc isn't seeing them.
>>>>
>>>> However, these shortnames are still used internally by ctype modules
>>>> to produce pretty concise source code, so move the short names to the
>>>> internal ctype_.h where short name conflicts shouldn't show up.
>>>> ---
>>>>   newlib/libc/ctype/ctype_.h     | 10 +++++
>>>>   newlib/libc/ctype/isalnum.c    |  2 +-
>>>>   newlib/libc/ctype/isalnum_l.c  |  2 +-
>>>>   newlib/libc/ctype/isalpha.c    |  2 +-
>>>>   newlib/libc/ctype/isalpha_l.c  |  2 +-
>>>>   newlib/libc/ctype/isblank.c    |  2 +-
>>>>   newlib/libc/ctype/isblank_l.c  |  2 +-
>>>>   newlib/libc/ctype/iscntrl.c    |  2 +-
>>>>   newlib/libc/ctype/iscntrl_l.c  |  2 +-
>>>>   newlib/libc/ctype/isdigit.c    |  2 +-
>>>>   newlib/libc/ctype/isdigit_l.c  |  2 +-
>>>>   newlib/libc/ctype/islower.c    |  2 +-
>>>>   newlib/libc/ctype/islower_l.c  |  2 +-
>>>>   newlib/libc/ctype/isprint.c    |  4 +-
>>>>   newlib/libc/ctype/isprint_l.c  |  4 +-
>>>>   newlib/libc/ctype/ispunct.c    |  2 +-
>>>>   newlib/libc/ctype/ispunct_l.c  |  2 +-
>>>>   newlib/libc/ctype/isspace.c    |  2 +-
>>>>   newlib/libc/ctype/isspace_l.c  |  2 +-
>>>>   newlib/libc/ctype/isupper.c    |  2 +-
>>>>   newlib/libc/ctype/isupper_l.c  |  2 +-
>>>>   newlib/libc/ctype/isxdigit.c   |  2 +-
>>>>   newlib/libc/ctype/isxdigit_l.c |  2 +-
>>>>   newlib/libc/include/ctype.h    | 67 ++++++++++++++++++----------------
>>>>   24 files changed, 69 insertions(+), 56 deletions(-)
>>>
>>> Good idea to move the _X macros to ctype_.h :)  Please push.
>>
>> i pushed this since it's standalone now.  not sure if you're also saying
>> "define _COMPILING_NEWLIB for all targets when compiling" is OK, so i haven't
>> pushed that yet.
> 
> Oh, that was implicitly clear to me, given the original dependency.
> So, yeah, please push.

+1
I've got a package build *NOT* failing with a redefinition of a couple 
of those short symbols to macros!

I will remind the author of the reserved symbols issue, and submit an 
upstream patch.

I will also report not failing as an upstream gcc error, as I don't 
think the compiler should just warn about those types of redefinitions.

But it would be good to see those short symbols lengthened and hidden 
from normal usage, as I have also seen those kinds of short symbols _? 
used as parameter and argument names in various sources.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]