From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by sourceware.org (Postfix) with ESMTPS id C5DA0388982F for ; Wed, 28 Jul 2021 20:13:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C5DA0388982F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rtems.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lf1-f49.google.com with SMTP id d17so6356811lfv.0 for ; Wed, 28 Jul 2021 13:13:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=6Z0p7vJ3eUAZOj5hnGw6ulRfeasylMWVR65tVBbKmg4=; b=dlC4qDa8jtY+OcWCAFUZYwE3ovfmWJiCjpRaVLk3TnelkqeOc77Vh56QUlYbpMS71w R0UCaDsmyzfXK8te6/Hjg5ExlwVbRGQWSBzVsiMYtBAue4jwNCHU/x9qZCW239dkxu/g hlYcpB16FE61JA1ATsHmqw6MJWa4XigLBtnedrfe6FG/6AuQs1A7KYDGGQ55QsGxUWHG FmHi5gWIXDWL5DEbML+DvrHvqzK61MfHpLrtgMuNj6cl9hPEN0YgJTlj5pd0w2kmO+35 DE0J0ahR1/BZyfZFXkwmCK2O6yE3aIuppahx4ga/nd//cICuTq4Ju3Lwe8+pFE67/HSK JlzQ== X-Gm-Message-State: AOAM531F/Q9OdcufKJZGaJVFrjVssnP5HdkxQo8yQNc09Ret+HJvT44X VbaxSadiAGV0LZkvbcr+B8Fpl514lQXvSQ== X-Google-Smtp-Source: ABdhPJwZgJUMtec+0YrMWJmWx3SGKU0CvZI7qawPlMcv87w9w6+t+HLflnJCyUKA3EUaganyZlTwdw== X-Received: by 2002:ac2:54a2:: with SMTP id w2mr948370lfk.283.1627503226191; Wed, 28 Jul 2021 13:13:46 -0700 (PDT) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com. [209.85.167.52]) by smtp.gmail.com with ESMTPSA id j1sm88112lfb.189.2021.07.28.13.13.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 28 Jul 2021 13:13:45 -0700 (PDT) Received: by mail-lf1-f52.google.com with SMTP id f18so6228749lfu.10 for ; Wed, 28 Jul 2021 13:13:45 -0700 (PDT) X-Received: by 2002:ac2:44c2:: with SMTP id d2mr1016951lfm.50.1627503225469; Wed, 28 Jul 2021 13:13:45 -0700 (PDT) MIME-Version: 1.0 References: <20210724083730.16959-1-mfjoyce2004@gmail.com> <20210724083730.16959-2-mfjoyce2004@gmail.com> <57f33efa-2450-ac5c-3ceb-be8beb183ca5@SystematicSw.ab.ca> In-Reply-To: Reply-To: joel@rtems.org From: Joel Sherrill Date: Wed, 28 Jul 2021 15:13:33 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Fw: [PATCH 1/1] libc: Added implementations and prototypes for To: C Howland Cc: Newlib X-Spam-Status: No, score=-3031.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Wed, 28 Jul 2021 20:13:50 -0000 On Wed, Jul 28, 2021, 2:54 PM C Howland wrote: > > > > ------------------------------ > > *From:* Newlib on > > behalf of Joel Sherrill > > *Sent:* Wednesday, July 28, 2021 3:42 PM > > *To:* Newlib ; Brian Inglis < > > Brian.Inglis@systematicsw.ab.ca> > > *Subject:* Re: [PATCH 1/1] libc: Added implementations and prototypes for > > > > > > On Wed, Jul 28, 2021 at 1:46 PM 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? > > > > > > Still pretty unsure, > > > > Me too. I told Matthew early on that the header guard for this was going > > to require discussion because I had no idea what was right. > > > > It would be nice to have this available on multiple platforms. Would it > be > > acceptable to make the header conditional on Cygwin and RTEMS for now? > > Can we conditionalize the C file for just those two? > > > It really does not matter a whole lot. The gates are only on the function > prototypes in the header file. It could just use the date of when the file > is added for the time being, really. > This isn't a bad idea. And similarly we could use May 2021 which is the date on Issue 8 Draft 2. To be more gung-ho, something like > #define POSIX8_RELDATE 202202 // FIXME WHEN REAL RELEASE DATE KNOWN > could be added to sys/features.h, and then this file could use that. > features.h will have to be edited when the new POSIX comes out, so just > place it appropriately to make the need to change it obvious. > I'm for this and use 202105. If a new draft comes out, maybe we bump it. Good thoughts Craig! --joel Craig > > > > > Does newlib have a ticketing/PR system? If so, we could revisit this when > > Issue 8 is released. Alternatively, we can file a ticket in Cygwin and > > RTEMS > > and see which one of us remembers it first after Issue 8 is out. I know > if > > we > > tag a ticket with the next release, it should get reviewed as we start > > cleaning > > up as the code gets slushier. > > > > --joel > > > > > Corinna > > > > > > > >