Re: [PATCH 2/2] ctype: use less short names in public header
Richard Earnshaw <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <[email protected]> |
On 24/11/2021 04:15, Mike Frysinger wrote: > On 23 Nov 2021 15:09, Richard Earnshaw wrote: >> This is wrong and breaks all old versions of C++. > > this is a bit vague. it would help if you provided details as to what broke. > i doubt this broke all old versions of C++ everywhere. My apologies, I did mean to say GNU C++. > > i'm guessing you're referring to the GNU C++ (libstdc++) library specifically > and its hardcoding of newlib's internal ctype define names. > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/config/os/newlib/ctype_base.h;hb=releases/gcc-11.2.0 > > if you're talking about something else, please state so clearly. > >> The GNU sim code should not be using reserved names (those starting _) >> in normal source code. Such names are reserved to the implementation. > > that's not really a good reason to go pooping all over the namespace. > It's not 'pooping' on the namespace. Identifiers starting with _ are all reserved, one way or another; some for the compiler, some for the library implementation and some for future changes to the standard. Applications have no business defining such names. > we can maintain backwards compat here for C++ code fairly easily: > > --- a/newlib/libc/include/ctype.h > +++ b/newlib/libc/include/ctype.h > @@ -71,6 +71,16 @@ enum > > /* For C++ backward-compatibility only. */ > extern __IMPORT const char _ctype_[]; > +#ifdef __cplusplus > +# define _U _ISupper > +# define _L _ISlower > +# define _N _ISdigit > +# define _S _ISspace > +# define _P _ISpunct > +# define _C _IScntrl > +# define _X _ISxdigit > +# define _B _ISblank > +#endif > > #ifdef __HAVE_LOCALE_INFO__ > const char *__locale_ctype_ptr (void); > > considering the numerical value is part of the ABI, not the name, libstdc++ > could have inlined the constant values instead. i wonder how long of a version > skew is reasonable if we wanted to transition it to the new names to match what > glibc uses. I think you'll find that the BSD libraries have been using _[ULNSPCXB] since pretty much forever. Why do we need to be compatible with glibc? R. > -mike >