From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id A7D163858C2C for ; Mon, 8 Nov 2021 22:22:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7D163858C2C 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-x434.google.com with SMTP id w29so17941553wra.12 for ; Mon, 08 Nov 2021 14:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jguk.org; s=google; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=gyWTD1ihKYBMsaw9g6VXP7vojAWosUIapNX5wi8u5iM=; b=Kla9hoiEJWgtd1zrsQrp5NA6kOP6fpFvHM5bq8AJ52nBWpLjtL+Gk1ceosxVKgJ8xo V8XpBoeevcnWWyLHlS6hBl/ClvHi/4jYnWqY4Ug082kT/4zvmHrofucxsDs1bdvxVIq/ Peib5jGG4WVD4BbVMlRwucUYkBzYTcPW763URKXi0nxVJ3H+aMPTkinUDBNnQqqKs9hc AWBojKaevrT3RIRyKVJSvn8+76LUAK0ADUqPikHgoVUtvRXHwMFqbdWCDxsvZlCWeMRD 1aONLVlflFeNyWLGItmPMXZsE61TE2bmlUHuRLsjRZ5Yd5s9df8JCA6JyR7UO9PAkC03 T79A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=gyWTD1ihKYBMsaw9g6VXP7vojAWosUIapNX5wi8u5iM=; b=EFs8dqv5n3cVMg+JOE1ylCkTZcpLPH/XUkFVt3mY3MYKxtqAIcpE9VS3d9N9jndGK6 XVnwo35oJq7rTaNpWw/cnDh1T02Xko8SjInMHC4V7oFD+hmKgdZ/Bgl3e8lZnkEbCGRJ +rKiebs+n5DEmgWAQ3ju7dKM2cql9f36dCr7jwPgwiEXfdOksjkmZBNpIBFtul9abht4 RAmOUAtenFYMsImdAoteGjnpUwfL7uXYGeJHAK3+6mpw4QyuhbDJ6SnJauxGzjSRjmLS CirOXrFHlbXRYly5pCxl8drHPeEzTeFfaVmxQbvouTPMqvEtPTaaPZSKbi542aQ2L22f Litw== X-Gm-Message-State: AOAM532dN5wGiSEFzPzXY9ay3lCVlMcAYPo2IL5imRSI5OZ61WKHYfkD wTTSpcjtojDiOyWs956NxZDGRA== X-Google-Smtp-Source: ABdhPJxSJwCCWSdSrrOp8mr0/VDPagFylfRxD2ifCp2woU2T+/OzUEdi/JEPSZq2XrNX+UWKbWCjkQ== X-Received: by 2002:a05:6000:156a:: with SMTP id 10mr3222053wrz.87.1636410157794; Mon, 08 Nov 2021 14:22:37 -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 r8sm21901755wrz.43.2021.11.08.14.22.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 14:22:37 -0800 (PST) From: Jonny Grant 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> Message-ID: <18f35159-daa5-a247-86ff-6a77eca49a2b@jguk.org> Date: Mon, 8 Nov 2021 22:22:36 +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: <4c43eab7-2ca8-1b90-5fb9-c84e26a96ef0@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.0 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: Mon, 08 Nov 2021 22:22:40 -0000 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. >> >> 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. >> >>> 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. Kind regards Jonny