[PATCH 2/2] ctype: use less short names in public header
Wed Nov 10 00:18:08 GMT 2021
On 09 Nov 2021 12:38, Corinna Vinschen wrote:
> On Nov 8 20:24, 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.
> Mixing newlib and glibc? That's just a typo, I guess?
i meant glibc here. these are the same symbol names that glibc is using,
and it's not seeing conflicts in the wider ecosystem. so if they aren't
seeing issues, it's likely newlib won't either if it uses the same names.
> > However, these shortnames are still used internally by ctype modules
> > to produce pretty concise source code, so use _COMPILING_NEWLIB to
> > keep them around when compiling newlib itself where we have better
> > control over short name conflicts.
> Hmm. I'm not sure we should really maintain two different sets of
> symbols. I think it would be better to go the entire way and replace
> the single letter symbols with the new, more speaking ones throughout.
> There are not that many affected files and the change might be done with
> sed mostly.
> The only exceptions *could* be libc/ctype/ctype_.c and the local
> ctype_iso.h and ctype_cp.h headers it includes. A local definition
> of the single letter symbols in ctype_.c would be sufficient then.
> But even there we might be better off with the new symbols in the long
i don't have an opinion. i can easily run sed on the files and send the
result out. i figured people would prefer having the condense tables so
they could scan them quicker by eye.
so let me know what you want and i'll do it ;).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Newlib