From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) by sourceware.org (Postfix) with ESMTPS id 1AE123858C3A for ; Tue, 9 Nov 2021 12:30:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1AE123858C3A Received: by mail-oi1-x22a.google.com with SMTP id bk14so10427458oib.7 for ; Tue, 09 Nov 2021 04:30:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=q78+hWbzrxcusynY3p9PZUWXTgRT0j03cVKgsVocedQ=; b=lC4Z3bR1G5Yf5d70qOSvyNy6wdwHswEyeL/ckPeVqiB2DVc+PHG957dIr4HmA5buQY v2ayqYng5SmAC3RCDud3cbBPrDi+eyeAaAQKq5GewGRVFlZvCk95MhD/zyIHw9zCbKOW pqC9t7oE6CnbINiUdhBr0LWcQNdXYzXHA35ImoPKKewuBIzNgqT4Fg92eZ93690caq2X meMx3UUAixxFaDc2TimBLIkLx7iWKZdphO7DS2sFqb52vx0/ylLM64CQi5hhXBPODOu1 LPB++vw5+rB1ytq/fE0+mW8v6EMtbWmiHqXcptoyopVw8rijaEFOTW1Vjge5/jeS6ZIx Q64g== X-Gm-Message-State: AOAM533zJxdlJi8JvB14BPLDms66IdIEX/stmLPIMaLwpuUNMJM0x7Q6 uX7hjfBWa+35RB9GZZDOn3FtNCtpMhAjRw== X-Google-Smtp-Source: ABdhPJzQniRwLUA3lR12Vgb9Dz+zfT7wYrU17J5vNV7S7vmDfwd4hp5pfcbKNirIFiXQct3Dc9M0GQ== X-Received: by 2002:a54:4f8f:: with SMTP id g15mr5224199oiy.178.1636461028392; Tue, 09 Nov 2021 04:30:28 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:55a:469b:f306:bf3e:39da? ([2804:431:c7cb:55a:469b:f306:bf3e:39da]) by smtp.gmail.com with ESMTPSA id n67sm7270727oib.42.2021.11.09.04.30.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Nov 2021 04:30:28 -0800 (PST) Message-ID: Date: Tue, 9 Nov 2021 09:30:26 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Subject: Re: glibc strerrorname_np Content-Language: en-US To: Jonny Grant , 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: Adhemerval Zanella In-Reply-To: <18f35159-daa5-a247-86ff-6a77eca49a2b@jguk.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.4 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 12:30:30 -0000 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. > >>> >>>> 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'.