Re: libstdc++ Chapter 28. Demangling example

[Jonny Grant <jg@jguk.org>]

On 12/04/2023 16:36, Jonathan Wakely wrote:
> On Wed, 12 Apr 2023 at 16:10, Jonny Grant <jg@jguk.org> wrote:
>>
>>
>>
>> On 04/04/2023 12:26, Jonathan Wakely wrote:
>>> On Fri, 31 Mar 2023 at 21:38, Jonny Grant wrote:
>>>>
>>>>
>>>>
>>>> On 31/03/2023 17:18, Jonathan Wakely wrote:
>>>>> On Fri, 31 Mar 2023 at 16:24, Jonny Grant <jg@jguk.org> wrote:
>>>>>>
>>>>>> Hello
>>>>>>
>>>>>> I tried out this code. Maybe I'm doing something wrong?
>>>>>>
>>>>>> https://godbolt.org/z/Y78h4f1W6
>>>>>>
>>>>>> https://gcc.gnu.org/onlinedocs/gcc-12.2.0/libstdc++/manual/manual/ext_demangling.html
>>>>>>
>>>>>> However only get reduced output after status -2 is returned:
>>>>>>
>>>>>> std::bad_exception      =>
>>>>>>
>>>>>> Looks like std::cout gets broken by the nullptr realname (that's a frustration). So I put an if(realname) in the godbolt link above.
>>>>>
>>>>> N.B. passing a null pointer to printf("%s", ptr) is undefined.
>>>>> Printing "(null)" is not required by the standards.
>>>>>
>>>>> Anyway, the exception classes haven't printed their mangled name for
>>>>> many many years, if they ever did. Only the second part of the
>>>>> example, using typeid, is valid.
>>>>
>>>> Ok I see. Is it better that the std::bad_exception part of the example is removed?
>>>
>>> Yes, done for GCC 13.
>>
>> Great!
>>
>>>>
>>>> c++filt doesn't demangle St13bad_exception either.
>>>
>>> c++filt needs the _Z prefix that identifies a mangled C++ name. The
>>> __cxa_demangle function doesn't need that.
>>>
>>> $ c++filt St13bad_exception
>>> St13bad_exception
>>> $ c++filt _ZSt13bad_exception
>>> std::bad_exception
>>
>> Ok that makes sense.
>>
>>>>>> Maybe it's also a good time to update the example abi::__cxa_demangle call from those 0 parameters to be NULL?
>>>>>
>>>>> Maybe nullptr.
>>>>
>>>> ok
>>>
>>> I didn't change them, using 0 as a null pointer constant seems OK.
>>
>> Isn't nullptr, or at least NULL better? NULL has always been used in C++ code, I've seldom seen 0 used professionally.
> 
> NULL is a macro, that requires inclusion of a header. nullptr is
> superior, but not available in C++98. 0 works OK here.

Fair enough. One of those headers must have included <cstddef> - I recall it did compile with NULL.

> 
>> abi::__cxa_demangle(ti.name(), nullptr, nullptr, &status);
>>
>> I did wonder, has anyone thought of introducing a C++ wrapper that outputs a std::string with the demangled name? That would avoid the caller needing to free the pointer.
>>
>> eg something like this, or similar.
>> int abi::__cxa_demangle_string(const std::string mangled_name, std::string & output_string);
> 
> The ABI is lower level than the standard library definition of
> std::string. It creates problems if <cxxabi.h> has a dependency on
> std::string.

Fair enough, applications can use a simple wrapper.

>>
>>>>
>>>> I noticed in libstdc++-v3/libsupc++/cxxabi.h
>>>>
>>>>    *  @note The same demangling functionality is available via
>>>>    *  libiberty (@c <libiberty/demangle.h> and @c libiberty.a) in GCC
>>>>    *  3.1 and later, but that requires explicit installation (@c
>>>>    *  --enable-install-libiberty) and uses a different API, although
>>>>    *  the ABI is unchanged.
>>>>
>>>> This refers to GCC 3.1 from 2002, is it safe enough to now remove that GCC 3.1 comment?
>>>
>>> It's still true, I don't see any need to remove it.
>>
>> True, but is stating the GCC version that demangling functionality was available via enabling libiberty relevant when someone is reading the latest version GCC 13 release? I can't think I need to know this was added in GCC 3.1 there must be countless things that aren't directly documented that have been introduced.
> 
> Is there somewhere better to document it? If not, removing it from
> there would make it harder to find the information. Is it really doing
> any harm?

You're right it doesn't harm, but maybe the history or ChangeLog is sufficient to document such memorials?
Just takes time to read about old versions when were in GCC 13 manuals
Jonny