libstdc++ Chapter 28. Demangling example

libstdc++ Chapter 28. Demangling example

[Jonny Grant]

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.

Maybe it's also a good time to update the example abi::__cxa_demangle call from those 0 parameters to be NULL?

Cheers, Jonny

Re: libstdc++ Chapter 28. Demangling example

[Jonathan Wakely]

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.

> Maybe it's also a good time to update the example abi::__cxa_demangle call from those 0 parameters to be NULL?

Maybe nullptr.

Re: libstdc++ Chapter 28. Demangling example

[Jonny Grant]

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?

c++filt doesn't demangle St13bad_exception either.

>> 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 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? 

Regards, Jonny

Re: libstdc++ Chapter 28. Demangling example

[Jonathan Wakely]

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.

>
> 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


>
> >> 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.

>
> 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.

Re: libstdc++ Chapter 28. Demangling example

[Jonny Grant]

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.

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);

>>
>> 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.

Jonny

Re: libstdc++ Chapter 28. Demangling example

[Jonathan Wakely]

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.

> 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.

>
> >>
> >> 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?

Re: libstdc++ Chapter 28. Demangling example

[Jonny Grant]

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

Re: libstdc++ Chapter 28. Demangling example

[Jonny Grant]

On 12/04/2023 17:07, Jonny Grant wrote:
> 
> 
> 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.
> 

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es47-use-nullptr-rather-than-0-or-null
ES.47: Use nullptr rather than 0 or NULL

Where there's a 0 in an example, it gets copy-pasted. If the example use nullptr, that's what is copy-pasted.

>>
>>> 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

Re: libstdc++ Chapter 28. Demangling example

[Jonathan Wakely]

On Tue, 18 Apr 2023 at 14:00, Jonny Grant <jg@jguk.org> wrote:
>
>
>
> On 12/04/2023 17:07, Jonny Grant wrote:
> >
> >
> > 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.
> >
>
> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es47-use-nullptr-rather-than-0-or-null
> ES.47: Use nullptr rather than 0 or NULL
>
> Where there's a 0 in an example, it gets copy-pasted. If the example use nullptr, that's what is copy-pasted.

Yes, exactly, and then it doesn't compile with -std=c++98

Re: libstdc++ Chapter 28. Demangling example

[Jonny Grant]

On 18/04/2023 15:49, Jonathan Wakely wrote:
> On Tue, 18 Apr 2023 at 14:00, Jonny Grant <jg@jguk.org> wrote:
>>
>>
>>
>> On 12/04/2023 17:07, Jonny Grant wrote:
>>>
>>>
>>> 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.
>>>
>>
>> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es47-use-nullptr-rather-than-0-or-null
>> ES.47: Use nullptr rather than 0 or NULL
>>
>> Where there's a 0 in an example, it gets copy-pasted. If the example use nullptr, that's what is copy-pasted.
> 
> Yes, exactly, and then it doesn't compile with -std=c++98

Isn't it reasonable for GCC13 examples to be based on c++11 these days? c++98 is already 25 years old.

Alas, the example doesn't compile with -std=c++98 due to missing
#include <cstdlib>

https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_demangling.html

https://godbolt.org/z/KjKfboqxG

This documentation for abi::__cxa_demangle  says both these can be NULL, it doesn't say 0. Feels better to follow the manual and change them to NULL.

char * 	output_buffer,
size_t * 	length, 

https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html

Jonny

Re: libstdc++ Chapter 28. Demangling example

[Jonathan Wakely]

On Tue, 18 Apr 2023 at 23:50, Jonny Grant <jg@jguk.org> wrote:
>
>
>
> On 18/04/2023 15:49, Jonathan Wakely wrote:
> > On Tue, 18 Apr 2023 at 14:00, Jonny Grant <jg@jguk.org> wrote:
> >>
> >>
> >>
> >> On 12/04/2023 17:07, Jonny Grant wrote:
> >>>
> >>>
> >>> 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.
> >>>
> >>
> >> https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es47-use-nullptr-rather-than-0-or-null
> >> ES.47: Use nullptr rather than 0 or NULL
> >>
> >> Where there's a 0 in an example, it gets copy-pasted. If the example use nullptr, that's what is copy-pasted.
> >
> > Yes, exactly, and then it doesn't compile with -std=c++98
>
> Isn't it reasonable for GCC13 examples to be based on c++11 these days? c++98 is already 25 years old.
>
> Alas, the example doesn't compile with -std=c++98 due to missing
> #include <cstdlib>
>
> https://gcc.gnu.org/onlinedocs/libstdc++/manual/ext_demangling.html
>
> https://godbolt.org/z/KjKfboqxG
>
> This documentation for abi::__cxa_demangle  says both these can be NULL, it doesn't say 0. Feels better to follow the manual and change them to NULL.
>
> char *  output_buffer,
> size_t *        length,
>
> https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.3/a01696.html

Fine, I'll change them. Can I focus on more important things now?