From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id D0D32385841D for ; Tue, 18 Apr 2023 13:00:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D0D32385841D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=jguk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=jguk.org Received: by mail-wm1-x32f.google.com with SMTP id v3so2449429wml.0 for ; Tue, 18 Apr 2023 06:00:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; t=1681822830; x=1684414830; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=c6fYuyFrBQsc3RlC/QCCLh2u3icjpNwx6OUksPmfTTk=; b=cszXJQRrIuSvafS9X3hYYc0qLL/hikxBOA/BY/C9jf8Me/ju6htJkjqmXhz8RobPZA z9JQpeCsn9p6AjVWfUUDr8FQWmAU6vexCTumCwal8FNTSDPZ4LJWasbLQxSdyc+aTXoK ErExnnEL0g6db1F0xNYN5xy2vwRR4iFHPOZJ5RlBom65ztmr9oM9OuoeAlR2GS0/8RAj u7Jn+ujmBhgR9dxYcfG/toA/VY9DG7NWrKr7563CGBzi0477GgBnoyj+wi5dl5iwoMk8 ICCmYDTTRoW7rM6HbbdCQ9gajAUVLJXDn+EuyWUlWIfv9M7htu7NuGRwhddNzEIkcSnc BoYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681822830; x=1684414830; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c6fYuyFrBQsc3RlC/QCCLh2u3icjpNwx6OUksPmfTTk=; b=fBh6QKkvQUSeyXeEZksbKFCAoMyXXG+PDS9o6Xkr9nLnXN8pph6kf8EL9d0sHmtYFC F7/WSBx2cvxCkAnoFGxhwwi5vKftmu/tmsNqDe0LXpdssmOHdVIZYBabfwvrZ7OavTjG DHq/Un/5hRbWGsXx40OomhOFyhwZlPOQtB6JJIneukgspx/5BZnBkknklxk52Okzm9av rOW59wXcAkB5Ef1rPVTTNb5fnOnmt6OKjvg/1/YsLfXhYVXQchXrJDZQZBfD7tX9V+1F xs+J/yVyyzXumZ59m0qDWC3+rh1Acbs2/onKzsy7dAxz5BEDHfYr6xIGO9PiXZnvWtiG ZoeQ== X-Gm-Message-State: AAQBX9dbtVM3o2QVpqnFRuOZV/nL+b5/rzOHrMMGcSa9/Fi/Vrh4fDaA FGzPJ98dX2eSYzOyi/dU+6EoAg== X-Google-Smtp-Source: AKy350aMkc/NBPOwFjIAvohRhAIGGDvfOagUEmXo5K/R71B6rGSia85LJbfUPi3WuPGDSgd7M51g9A== X-Received: by 2002:a05:600c:2193:b0:3f1:79b3:a594 with SMTP id e19-20020a05600c219300b003f179b3a594mr1782755wme.3.1681822830552; Tue, 18 Apr 2023 06:00:30 -0700 (PDT) Received: from [192.168.0.12] (cpc87345-slou4-2-0-cust172.17-4.cable.virginm.net. [81.101.252.173]) by smtp.gmail.com with ESMTPSA id z16-20020a5d4c90000000b002c7163660a9sm13056306wrs.105.2023.04.18.06.00.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 18 Apr 2023 06:00:30 -0700 (PDT) Message-ID: Date: Tue, 18 Apr 2023 14:00:29 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: libstdc++ Chapter 28. Demangling example From: Jonny Grant To: Jonathan Wakely Cc: Jonathan Wakely , libstdc++@gcc.gnu.org References: <03e9c7d6-95a0-bd2e-fa31-91919ad76f3f@jguk.org> <66cc512c-f341-eda5-4e9a-8066f59e829f@jguk.org> <1b8d08b9-cef0-e828-7bf3-77f71167b66d@jguk.org> <11a260c8-a3e5-38e2-38fa-871f4edf2f67@jguk.org> Content-Language: en-GB In-Reply-To: <11a260c8-a3e5-38e2-38fa-871f4edf2f67@jguk.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 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 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 - 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 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 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