From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 1D3253959C14 for ; Wed, 29 Apr 2020 11:57:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1D3253959C14 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jTlLW-00045j-CI; Wed, 29 Apr 2020 11:57:46 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jTlLW-0000Cc-8U; Wed, 29 Apr 2020 13:57:46 +0200 From: Florian Weimer To: Adhemerval Zanella Cc: Adhemerval Zanella via Libc-alpha Subject: Re: [PATCH 2/5] signal: Move sys_siglist to a compat symbol References: <20200427214855.2523259-1-adhemerval.zanella@linaro.org> <20200427214855.2523259-2-adhemerval.zanella@linaro.org> <87blnbpsv2.fsf@mid.deneb.enyo.de> <7f5ae16a-b44c-792f-d00f-06d25c63d432@linaro.org> <87r1w7odaw.fsf@mid.deneb.enyo.de> <87blnaeh5u.fsf@mid.deneb.enyo.de> Date: Wed, 29 Apr 2020 13:57:46 +0200 In-Reply-To: (Adhemerval Zanella's message of "Wed, 29 Apr 2020 08:40:59 -0300") Message-ID: <87d07qcxmt.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Wed, 29 Apr 2020 11:57:49 -0000 * Adhemerval Zanella: >>> And even its usage is not fully portable (solaris11 defines as >>> _sys_siglist, AIX 73 does not provide it). So I am not sure if we >>> should continue provide for newly binaries. >> >> Another difference is that the variables are async-signal-safe. >> strerror and strsignal might not be if the argument is out of range >> (something that can be checked with the count variable in the other >> case). At least our strsignal is already thread-safe. >> > > We have strerror_r at least as an extension. It's not an extension, but GNU has a different prototype. This makes this interface really hard to use unfortunately. Hence my desire for a thread-safe strerror (which everyone assumes anyway). > >> I'm going to propose errno_constant and signal_constant functions to >> cover the async-signal-safe case. Let's see if they gain positive >> feedback from the larger libc community. > > Instead I think it would be better just simplify glibc strerror > and strsignal assumptions to *not* return locale dependent messages > and add a strsignal_l for the case. > > So strerror/strsignal will just directly access the underlying error > with the expected bound error checks and thus be asignal-safe. There's still the formatting of unknown errors and signals. I'm not sure if we want to regress there. (Userspace can sometimes see invalid errors from kernel subsystems.)