Re: Fw: [cxx-abi-dev] Decimal Floating Point mangling was(Fw: [cxx-abi-dev] C++0x: Mangling of rvalue reference type)s

[Michael Wong <michaelw@xxxxxxxxxx>]

Sorry for the delayed reply. But here are my thoughts.

Michael Wong
XL C++ Compiler kernel Development
IBM Canada Ltd., C2/KD2/8200/MKM
8200 Warden Avenue
Markham, Ontario  L6G 1C7
W:905-413-3283 F:905-413-4839
Boost test results
http://www-1.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&uid=swg27006911

C/C++ Compilers Support Page
http://www.ibm.com/software/awdtools/ccompilers/support/
C/C++ Feature Request Interface
http://www.ibm.com/support/docview.wss?uid=swg27005811
XL Fortran Compiler Support Page
http://www.ibm.com/software/awdtools/fortran/xlfortran/support/
XL Fortran Feature Request Interface
http://www.ibm.com/support/docview.wss?uid=swg27005812

Dennis Handly <dhandly@xxxxxxxxxx> wrote on 08/11/2007 02:37:05 AM:

> >From: Michael Wong <michaelw@xxxxxxxxxx>
> >While I believe this encoding is slightly better, unfortunately, we have

> >productized this based on the earlier agreement ...
>
> >I realize this is not the best encoding, but many other single letter
> >encoding do not represent their actual names.
>
> I thought the Standards committee is still deciding whether decimal
> floating point is a builtin type or a class?
This is the area where the C++ Std differs from the C std.
C++ Std has DFP as a class because of its preference and philosophy of
introducing new ideas as classes, not as a builtin type as required by the
C Std. However, some C++ compilers will need to start to accept many of
these mangling in their ABI inorder to maintain C interoperability. We
introduce many C99 concepts too into the C++ ABI even though they are not
required from the C++ Std for simialr reasons.
>
> The later would just be encoded as length then name.
> Of course this can be handled as "5.1.7 Compression ... abbreviations for
> certain common names".
>
> And this form is mentioned:
> ... the following catalog of abbreviations of the form "Sx" are used:
>
> Or we just go with what Michael has and documented it well and point to
> the "right" way to do it next time??  (And who to blame.  ;-)
The library case will be mangled that way. But for C interoperability it
won't work. This is to cover the case for vendors who actually wish to
implement them as builtin types.
(I would still be happy to accept the blame.)