From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id CD2F03858404 for ; Tue, 9 Nov 2021 23:01:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CD2F03858404 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-x42a.google.com with SMTP id w29so586670wra.12 for ; Tue, 09 Nov 2021 15:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=EeLBGRZWD1C5/Evr718S1mPD0G6oaxVFyALi+n1aYP4=; b=DBXVSJuVT/sNbBD1UiariXXKPppbYZr+ghQIwgF14YWG7jZPh9Z32KPnSSzwEAkgf9 mSh7iNvkVBlCwJ85KtqoLh/bWtG0LMKRmI78mM4l59c4K89KvcX4vcyQqdHsj/t0v4XL 7TW5XLHkI3FKGRPlNDP7Aw7BQWqituay3Xyb+6I6BUZj3zZeNQlqa09WdK4FwIu5uDvl llIqyf1j/d0DbSOy/VCtlI2xmqlH3AFqm0wGqBDr3zinHOLYyLLgAPDnqdnoBe9aqFua F2O84W0w//MtB0Nl7DyGJ3uFxHpDHiDdUTcJdyoK01ZSCPLDR1oVYlu1nuhT/tZ4RsfE Y44g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EeLBGRZWD1C5/Evr718S1mPD0G6oaxVFyALi+n1aYP4=; b=0/YCjbgEyBQ8jp4huBcmgmr+BD5i2zr9Zjg8d/JiridxeHkrGOtZCXV++SC6rwjt/Y YkU3q+HlWDr029YMzKGLMmhr6hvmnOqjZfdOVUqbUwQFltIu6LoihnVNwDhGpJO/Koku VzitYKGiEqqatApuAoP3FHtnDxWT5RvGckPbwk8plNrykzvhlamzKqnFmP9wvlnsITkK sih/m5BJP9kwTX8grdYqYmww/eHl1N80LRXNOBC9H3Ze96VVPZX47ssiCJHL6kCDEoho tmy15iWWbFrbh+YbSIJSVlU7d81McSG5y8xzzIxTjQRrNYMoD/Rc0hkr7vCWVXyT1Q7z UUOw== X-Gm-Message-State: AOAM533dWSWcgwK986TavxCQJf9KsFA6wDc00HI4kYs24dcrB3zczcL6 IzxjI/KCgdo9hkxgMSgZiznb2VLbIY7zcA== X-Google-Smtp-Source: ABdhPJzAj1jxKyt5Qe6cHf8RMQiNgo4HbvWHj4vcDlJB37x83gZTZkAJIRkcuvOeSXAR1Xwg0sV49A== X-Received: by 2002:a5d:59a2:: with SMTP id p2mr14487553wrr.252.1636498906821; Tue, 09 Nov 2021 15:01:46 -0800 (PST) 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 d7sm20983410wrw.87.2021.11.09.15.01.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Nov 2021 15:01:46 -0800 (PST) Subject: Re: glibc strerrorname_np To: Adhemerval Zanella , libc-alpha@sourceware.org References: <98556e3e-2869-64f0-574e-7a64503185c2@linaro.org> <9613b21a-3ab0-3303-9321-7bf4e36ce7ed@jguk.org> <77e058e8-2f54-46a5-2180-9784f23040e7@linaro.org> <4f5422c1-d6ea-1ea5-eeea-db61f8b95bc8@jguk.org> <66a2e472-d4e2-96bb-d1a5-8bafa795083f@linaro.org> <4c43eab7-2ca8-1b90-5fb9-c84e26a96ef0@linaro.org> <18f35159-daa5-a247-86ff-6a77eca49a2b@jguk.org> From: Jonny Grant Message-ID: <00c5d718-eaca-886c-ac02-73879c745a56@jguk.org> Date: Tue, 9 Nov 2021 23:01:45 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 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.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 23:01:49 -0000 On 09/11/2021 12:30, Adhemerval Zanella wrote: > > > On 08/11/2021 19:22, Jonny Grant wrote: >> >> >> On 06/11/2021 12:51, Adhemerval Zanella wrote: >>> >>> >>> On 05/11/2021 19:23, Jonny Grant wrote: >>>> >>>> >>>> On 05/11/2021 13:01, Adhemerval Zanella wrote: >>>>> >>>>> >>>>> On 05/11/2021 08:51, Jonny Grant wrote: >>>>>>> >>>>>> >>>>>> Hi Adhemerval >>>>>> >>>>>> Thank you for your reply. Personally I understood an ABI break would be the return type, the name, or the parameters. But the proposed change is not so. Changing to return a string, should be fine. >>>>> >>>>> It is still an ABI break, code that checks NULL for invalid input will >>>>> stop to work. >>>>> >>>>>> >>>>>> ie, in relation to strerror() C99 and POSIX.1-2008 require the return value to be non-NULL. (my view is it is always better not to return a NULL from such string functions that could then cause a SEGV. >>>>>> >>>>>> strerror(1000) returns a string "Unknown error 1000" >>>>>> >>>>>> Better to simply align with glibc strerror() approach? >>>>>> >>>>>> Feels like there is still time to change it, as it is _np. Aligning with strerror(), or just "" as you had mentioned seems reasonable. >>>>> >>>>> I give you that it is indeed a better return code, and it is not a matter >>>>> of timing, but rather I don't think it really worth the ABI break and >>>>> the required code complexity to do so. >>>>> >>>>> It would require: >>>>> >>>>> 1. Change the strerrorname_np to return "" on invalid code. >>>> >>>> Please find attached the patch. >>>> >>>>> 2. Keep the compat symbol that returns NULL and add a compat symbol. >>>>> 3. Exports a new symbol with version on 2.35 with the new semantic >>>>> and update the ailist. >> >> Could you dircet me to the ailist file you mention please. > > I spelled it wrong, it should be 'abilist': > > $ find . -iname *.abilist > ./sysdeps/unix/sysv/linux/x86_64/64/libBrokenLocale.abilist > ./sysdeps/unix/sysv/linux/x86_64/64/libm.abilist > ./sysdeps/unix/sysv/linux/x86_64/64/libutil.abilist > [...] > > You can check if the exported symbols are on par with the pre-defined > ones with: > > $ make check-abi > > And you can update the abilist files with: > > $ make update-abi > > It will need to be properly exported on the 'Versions' file. > > >> >>>> >>>> May I check, why would a new symbol be needed? I'd expect it is only a change to strerrorname_np and any test code you have that presently checks for NULL return. >>> >>> As I said before it is an ABI break, since users that check for invalid >>> errno against NULL will start to fail. For such change we *do need* all >>> the trouble of adding a compat symbol with current semantic. >> Many thanks for your reply. May I check, are even the _np functions set in stone once they are released? glibc strerrorname_np was released a year ago. My disto Ubuntu LTS doesn't yet have this new glibc release containing this function. > > It is not a matter of time, neither glibc is tied to any distribution. It is > a matter or point release, for instance 2.34. Once we export such symbol on > a release, programs will be built against and depend of the symbol. Ok I see. It's also tricky as I'd prefer to not define _GNU_SOURCE What do you think of the possiblity of adding something like strerrorname() directly without _GNU_SOURCE, and always returning a valid string, or empty string? With a consistent return for an errnum of 0. strerror_r(0, &b, 0); already returns "". strerror(0) returns "Success" So there is some inconsistency in the POSIX functions. >> >>>> >>>>> 4. Update the documentation and sync with man-pages. >>>> >>>> The man-page update is minor, I could handle that. >>>> >>>> >>>>>> https://man7.org/linux/man-pages/man3/strerror.3.html >>>>>> >>>>>> It's common for some returns to change, eg glibc 2.13 changed strerror_r() behaviour to return the actual error code, as opposed to returning -1 and setting errno. >>>>> >>>>> And such change did got without burden and extra complexity. Just check >>>>> the multiple preprocessor checks it requires to get the right definition >>>>> depending of the system support on the misc/error.c (imported from gnulib). >>>>> >>>> >>>> Ok, I think the change I propose does not affect the definition, as the function signature is the same. Maybe I misunderstand something. >>> >>> The ABI break is not only for function signature and input alignment/size, >>> but also for function semantic. Just check the fmemopen >>> (fdb7d390dd0d96e4a8239c46f3aa64598b90842b), where we kept the old buggy >>> implementation since even when it is not POSIX compliant because we do >>> not know if users do depend of such behavior. >>> >> >> I was reading the fmemopen ticket you shared. May I ask - could you direct me to a "compat symbol" description? I did search and came across libc_hidden_proto and see it in use in /glibc/include/stdio.h the patch commit note says update fmemopen to the new POSIX spec. > > To put simply, the 'compat symbol' is a GNU extension that creates a > symbol tied to an specific version where a linked program built against > an older glibc will continue to use the older version instead of the > default one. > > There is some information on how it is created internally on > 'include/shlib-compat.h'. > I see. Thank you for explaining. Kind regards Jonny