From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) by sourceware.org (Postfix) with ESMTPS id 7DB6138930E6 for ; Thu, 29 Jul 2021 02:51:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DB6138930E6 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=systematicsw.ab.ca Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id 8vSdmVO9hFRDp8w8pmssz3; Thu, 29 Jul 2021 02:51:23 +0000 Received: from [192.168.1.104] ([68.147.0.90]) by cmsmtp with ESMTP id 8w8pmeRXpB9dP8w8pmuAQM; Thu, 29 Jul 2021 02:51:23 +0000 X-Authority-Analysis: v=2.4 cv=Ac10o1bG c=1 sm=1 tr=0 ts=610217ab a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=uZvujYp8AAAA:8 a=uYT-Tk0qkVT609LjNaIA:9 a=QEXdDO2ut3YA:10 a=IQaOWYEeq0kA:10 a=n_Xaztpbb70A:10 a=SLzB8X_8jTLwj6mN0q5r:22 Reply-To: newlib@sourceware.org Subject: Re: [PATCH 1/1] libc: Added implementations and prototypes for To: newlib@sourceware.org References: <20210724083730.16959-1-mfjoyce2004@gmail.com> <20210724083730.16959-2-mfjoyce2004@gmail.com> <57f33efa-2450-ac5c-3ceb-be8beb183ca5@SystematicSw.ab.ca> From: Brian Inglis Organization: Systematic Software Message-ID: Date: Wed, 28 Jul 2021 20:51:23 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4xfGI7jgp90oa1dfsvQZyUp/2Tus4lFfqyu7CFEJN9OtSPPF4XmWXxrlihJry1w94TU+zCJytyV8MdTz1Nb39nWBB1wq7KrdeO6j63HSOa33ipL59UoSfX 8Iq47j7wv7hIOEX9yomYwfr6JvFE/yG4pBcvLD2uEWMrZgIOlR83r8EvR7426zqi759cDaWN+3ckpAqUF4qoDJ3EaE5HUhPSzQU= X-Spam-Status: No, score=-1161.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no 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 02:51:26 -0000 On 2021-07-28 12:46, Corinna Vinschen wrote: > On Jul 28 09:25, Brian Inglis wrote: >> On 2021-07-28 03:11, 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. >>> >>> If anybody has better information or a good idea how to guard this new >>> API in the meantime, I'm all ears. >> >> Current values are: >> >> __POSIX_VISIBLE 199009 >> __POSIX_VISIBLE 199209 >> __POSIX_VISIBLE 199309 >> __POSIX_VISIBLE 199506 >> __POSIX_VISIBLE 200112 >> __POSIX_VISIBLE 200809 >> __POSIX_VISIBLE 201402 >> >> and anticipated release date is 2022 from FAQ >> >> https://www.opengroup.org/austin/faq.html >> >> Q8. Where is the schedule for draft development? >> >> so could use: >> >> __POSIX_VISIBLE >= 202202 /* FIXME when POSIX Issue 8 released */ > > Did you mean 202201? Sounds like a good idea in theory. But consider a > project actually using this value and then the POSIX release defines the > value 202207 or so. The project might stop to compile correctly. Along > these lines, using 202212 for the interim might be the better approach. > Then again, what if the release occurs in 2023 only? Best guess of earliest release (V8 exactly 8 years after V7 - spooky!) Jan too early in year for consensus agreement and release process. Actual value could be later if defined (if so likely 202209 from history - couple months after NA vacation period) so will still test true. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]