Re: [PATCH] uchar.h: define char16_t and char32_t for old c++

[Szabolcs Nagy <nsz@port70.net>]

* Joakim Sindholt <opensource@zhasha.com> [2018-07-09 11:20:05 +0200]:
> On Sun, Jul 08, 2018 at 03:19:03PM +0200, Szabolcs Nagy wrote:
> > including uchar.h in c++ code is only well defined in c++11 onwards
> > where char16_t and char32_t type definitions must be hidden since they
> > are keywords.  however some c++ code compiled for older c++ standard
> > include uchar.h too and they need the typedefs, this fix makes such
> > code work.
> > ---
> >  include/uchar.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uchar.h b/include/uchar.h
> > index 8dabf1ed..7e5c4d40 100644
> > --- a/include/uchar.h
> > +++ b/include/uchar.h
> > @@ -3,7 +3,9 @@
> >  
> >  #ifdef __cplusplus
> >  extern "C" {
> > -#else
> > +#endif
> > +
> > +#if __cplusplus < 201103L
> >  typedef unsigned short char16_t;
> >  typedef unsigned char32_t;
> >  #endif
> > -- 
> > 2.16.3
> 
> Isn't this a bit ill advised? I just did a little test to see how GCC
> mangles the names and it looks troublesome:
> char16_t func(char32_t *s); becomes _Z4funcPDi when -std=c++11
> and when we add
> typedef unsigned short char16_t;
> typedef unsigned char32_t;
> and compile it with -std=c++03 it becomes _Z4funcPj
> 
> Did I do something egregiously wrong? Because this seems like a recipe
> for ABI incompatibility.

yes, same thing happens with glibc, if a project uses pre-c++11
compilation setting and includes uchar.h then it will have
different abi.

this is a problem if it uses or provides extern C++ interfaces
with these types.

i would normally say that we shouldn't support such broken code,
but this is c++ where things are broken no matter what.