Re: [PATCH 2/2] ctype: use less short names in public header

On Nov  9 19:18, Mike Frysinger wrote:
> 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
> > run...
> 
> 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 ;).

Great.  Let's try the compromise from above: Drop _X etc from the
header, just define them in libc/ctype/ctype_.c.


Thanks,
Corinna