Re: ctype.h macros may conflict with C++11 UDL

[Richard Damon <Richard at Damon-Family dot org>]

On 10/10/18 6:59 AM, Corinna Vinschen wrote:
> On Oct  9 18:03, Glenn Elliott wrote:
>> Hello newlib maintainers,
>>
>> ctype.h “#define"s the following values: _U, _L, _N, _S, _P, _C, _X, and _B.
>>
>> These macros may conflict with C++11 user defined literals (UDL) (https://en.cppreference.com/w/cpp/language/user_literal <https://en.cppreference.com/w/cpp/language/user_literal>).  It’s easy to see how C++11 UDL suffixes might conflict it the macros defined in ctype.h.  For instance, one may define a UDL function of “_N” to instantiate a C++ type that represents newtons of force.  Indeed, this is done by this units library: https://github.com/nholthaus/units <https://github.com/nholthaus/units>
>>
>> Must these macros leak from ctype.h?
> Yes, they have to, otherwise the isXXX ctype macros can't be resolved
> successfully.  Am I the only one thinkiong it was a bit non-considerate
> of the C++ standarization commitee to use the underscore in a way 
> potentially colliding with implementation-defined symbols.
>
> Probably the most feasible workaround is to change those macros to
> double underscores throughout.
>
>
> Corinna
>
The normal criteria described for the Standard is that it works very
hard to try to not break existing USER code, so users don't need to
change (much) existing working code to move it to a new standard. There
is little such effort for implementations. Implementations, in general,
will need to have potentially very significant changes to implement the
new features of the new Standard, so needing to make minor internal
changes to get around new defined names is expected.

This is why, in general, any new 'keyword' will be defined in the
implementation name space, with some active change in the program needed
to make it 'nicer' and affecting user name space.

-- 
Richard Damon