From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 6204E3861838 for ; Thu, 29 Jul 2021 14:41:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6204E3861838 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1627569670; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kJxIqieb8FNviDUr/VYkq8eau9PpkFOtv+5CVSonWIs=; b=byImxZ3pkXrYJw8uw/sko935LPItVyv3uNCVxX76xLlc7XJu7r0ajRBpHBLffvoNXq5Qm5 +6iRJh8BCRTmFbndnKTZSODlJ4/03/99gHUVvoSgovLvLWWPIoorIT1b9EaMbq09tsLKbJ U2tjB6EXbVOcJjXYC0o8Vtgy6a/IRGU= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-190-zh8eORndM8-0I3sAhU4GcQ-1; Thu, 29 Jul 2021 10:41:07 -0400 X-MC-Unique: zh8eORndM8-0I3sAhU4GcQ-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C8F0658E3; Thu, 29 Jul 2021 14:41:06 +0000 (UTC) Received: from redhat.com (ovpn-114-43.phx2.redhat.com [10.3.114.43]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8AB8B60843; Thu, 29 Jul 2021 14:41:06 +0000 (UTC) Date: Thu, 29 Jul 2021 09:41:04 -0500 From: Eric Blake To: Matt Joyce , newlib@sourceware.org Subject: Re: [PATCH 1/1] libc: Added implementations and prototypes for Message-ID: <20210729144104.hbw5utb2whgmcgez@redhat.com> References: <20210724083730.16959-1-mfjoyce2004@gmail.com> <20210724083730.16959-2-mfjoyce2004@gmail.com> MIME-Version: 1.0 In-Reply-To: User-Agent: NeoMutt/20210205-678-cae0f0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=eblake@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2021 14:41:11 -0000 On Wed, Jul 28, 2021 at 11:11:04AM +0200, Corinna Vinschen wrote: > Hi Matt, > > thanks for this v2. > > On Jul 24 10:37, Matt Joyce wrote: > > Added implementations for sig2str() and str2sig() in libc/signal in order > > to improve POSIX compliance. Added function prototypes to sys/signal.h. > > Added Makefile.am entries to build the new file. > > --- > > [...] > > +#if __GNU_VISIBLE > > I think this needs discussion. The sig2str/str2sig API has not been > provided yet by GLibC. Using __GNU_VISIBLE in this context looks wrong. > What we need, in fact, is a __POSIX_VISIBLE guard, but here's the > problem: As far as I can see, the Issue 8 draft does not yet define a > version number. Correct. As of draft 2 (May 2021), the text of XSH 2.2.1P8 has been amended to read: For the C programming language, shall define _POSIX_C_SOURCE to be 20yymmL | before any header is included The goal is that draft 3 will be the first draft of Issue 8 that finishes the intended update of POSIX from C99 (the base standard used in Issue 7, and in the 2017 document) to C17, and as part of that update, it will align any new macros, interfaces, and so forth required by the move to the newer C standard. The current status reports say draft 3 may come as soon as Q3 of 2021 (https://www.opengroup.org/austin/docs/austin_1148.txt), but September is coming up pretty fast. The actual date chosen for _POSIX_C_SOURCE will probably be picked to align with when Issue 8 is completed, which will not be any sooner than late 2022. > > If anybody has better information or a good idea how to guard this new > API in the meantime, I'm all ears. I think as long as we pick an arbitrary date in the future, then refine it to the actual date once one is known, we're probably okay. No portable code should care what date we picked in the short term (code portable to Issue 8 will pick the final date, and in the meantime, code trying to comply to Issue 8 is already non-portable since Issue 8 is still in flux). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org