From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) by sourceware.org (Postfix) with ESMTPS id D5E293858D28 for ; Wed, 12 Apr 2023 16:07:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D5E293858D28 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-wr1-x431.google.com with SMTP id e22so11357287wra.6 for ; Wed, 12 Apr 2023 09:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; t=1681315642; x=1683907642; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=0ueWFEGLjtwX9VbyFInlhcUCfInL84yHRbj1AFqNeCo=; b=OyP+MYJeM+4DuGvZIddxQBE1FPf+SlI8XYf1Y8QBFU3Ugp0FxmGa0lf2n67T5KX1Ip 2e4NkSvB93Yc66HSBgcl/HDfszPo5MoBVN1EWuMoHxjMS2KJIv0pljyODcPi3PY1XZ7i lVEGTCWHS0678GJWOs7GIGyllcnTWd7C7V2Mp55hBi5pfvc6gjKu31f2+pfRuG2Rxo+D oNZWXGRpli5hNufN2T2UWwU0St48UtqvPVMaukl4b/LuOBhlJbYVwJEi5BpBnC7hAoxi 2lw1SITa+mbbhZUtJ5GzIPWmmWSOTBRrYCVpBk98eT8iwwlWutQfSEzSyyJfzCqskOOJ qolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681315642; x=1683907642; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0ueWFEGLjtwX9VbyFInlhcUCfInL84yHRbj1AFqNeCo=; b=ZaYDfwkjoI7NEXKv6BdB5BnBnpa8JUxrwKzwFq1SU3sS7F5QnIxKMVEkUehRq9Zq39 FMV0JevHyrRgrWbLeNMASeostpHD2IN5EMrwDzAVL24qX1VQlFxzFBGQyk/M6QLiJpjc pvt5uCfVUhhuwq2iYY89iMHRy58yOlIZtAE/sqNuy9Hi5V1pxq9FH0P9pzrBXwubMUaz 5c1mvmWj+zgyE0AFTUf3Cwyj7CeM5bpPRMTknxAQG4iVzZrMtKV3gmUxZIJCSb587JCk +4pHEPmDLSXJ756aBsEXS4FOB7GCJvQ4J+WWdZHnCXjaTuqWgDe10lissYNnYSxsbvYT k56Q== X-Gm-Message-State: AAQBX9fFLC1lpcu6uHnb84IDXtX10l0Bp61HYtVAbuYXO5pvZOAHJqkM 9WeqyuU32KuHAdIdjfSPOGA/cw== X-Google-Smtp-Source: AKy350b76v13XBZHYIm8ztkjjW7v48gz8AFyBxRYzuWworgNUulylhZDMOzxlvUn7mbQA9VhjFaVAA== X-Received: by 2002:a5d:6ad1:0:b0:2ce:ae4c:c429 with SMTP id u17-20020a5d6ad1000000b002ceae4cc429mr5151959wrw.4.1681315642586; Wed, 12 Apr 2023 09:07:22 -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 k8-20020adfd848000000b002f0075ccf7bsm10220063wrl.71.2023.04.12.09.07.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Apr 2023 09:07:22 -0700 (PDT) Message-ID: <11a260c8-a3e5-38e2-38fa-871f4edf2f67@jguk.org> Date: Wed, 12 Apr 2023 17:07:21 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: libstdc++ Chapter 28. Demangling example Content-Language: en-GB 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> From: Jonny Grant In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 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 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 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. > >> 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