Re: [PATCH v2] ctype: use less short names in public header
Brian Inglis <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Organization | Systematic Software |
| Message-ID | <[email protected]> |
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.]