[PATCH v2] ctype: use less short names in public header
Sat Nov 20 20:08:50 GMT 2021
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.
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
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.]
More information about the Newlib