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 8B5693857830 for ; Thu, 8 Apr 2021 11:56:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8B5693857830 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=vinschen@redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617882989; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=GOEp+89I4PL2To32qF58YIT6jhXrmtFZRhmOC7BlJso=; b=Or80b/Mnna950FEOP6SYfD74Si6oV1cyoQnToAORhKty9R5dVSulzUO9lkuwERaIMx0tWY tbEldMonGa2zCjKGpyVf4U0a0ktftM5EXfirFEB0pHMEZfobLFNyjgMnps7NhDqxA9cyAj tr98oJ10Ew0KSYrfnQxxsIz+qUNK/e4= 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-372-D3_G5Z0cPhuy_WXp4zXKrw-1; Thu, 08 Apr 2021 07:56:27 -0400 X-MC-Unique: D3_G5Z0cPhuy_WXp4zXKrw-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 896491006C82 for ; Thu, 8 Apr 2021 11:56:26 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-112-38.ams2.redhat.com [10.36.112.38]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5914D19CB0; Thu, 8 Apr 2021 11:56:26 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id EA414A80E42; Thu, 8 Apr 2021 13:56:24 +0200 (CEST) Date: Thu, 8 Apr 2021 13:56:24 +0200 From: Corinna Vinschen To: newlib@sourceware.org Subject: Re: APIs in New POSIX Edition Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: newlib@sourceware.org, Yaakov Selkowitz References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=vinschen@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Spam-Status: No, score=-7.1 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_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: 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, 08 Apr 2021 11:56:30 -0000 On Apr 8 13:49, Corinna Vinschen wrote: > On Apr 8 06:38, Joel Sherrill wrote: > > On Thu, Apr 8, 2021, 6:19 AM Corinna Vinschen wrote: > > > > > On Apr 7 18:26, Joel Sherrill wrote: > > > > Hi > > > > > > > > https://www.opengroup.org/austin/docs/austin_1110.pdf includes a set of > > > new > > > > methods to be added to the POSIX standard. RTEMS has a potential GSoC > > > > student interested in working down the list for RTEMS. Some of these make > > > > sense to be implemented in newlib. All will end up being prototyped in > > > > newlib headers somewhere. > > > > > > > > >From the document and the formatting is completely lost. > > > > > > > > The additional APIs proposed by participants in the Austin Group that > > > The > > > > Open Group has agreed to sponsor are as follows: > > > > > > > getentropy() > > > > memmem() > > > > reallocarray() > > > > strlcat() > > > > strlcpy() > > > > wcslcat() > > > > wcslcpy() > > > > > > Already in newlib. > > > > > > > ppoll() > > > > > > Already defined in Cygwin. We don't have a generic poll.h header in > > > newlib. > > > > > > > dladdr() > > > > > > Already defined in Cygwin. We don't have a generic dlfcn.h header in > > > newlib. It's questionable if this really belongs in newlib. > > > > > > > getlocalename_l() > > > > posix_getdents() > > > > sig2str() > > > > str2sig() > > > > > > No worries as soon as the API is stable. > > > > > > > pthread_cond_clockwait() > > > > pthread_mutex_clocklock() > > > > pthread_rwlock_clockrdlock() > > > > pthread_rwlock_clockwrlock() > > > > qsort_r() > > > > sem_clockwait() > > > > > > No worries, these APIs won't change compared to their already > > > existing implementations in GLibc. > > > > > > > Great. > > > > What feature guard should these be behind? Will it change for the ones > > already in place? > > There will be a matching POSIX.1-2021 or so, given by date/month, > with guards along the lines of _POSIX_C_SOURCE >= 202107L. > > APIS we already have should keep their current guard or'ed with > the above _POSIX_C_SOURCE test. > > APIs we already have but have no guard should get _DEFAULT_SOURCE > or'ed with the above _POSIX_C_SOURCE test. There are also APIs which already exist per an older POSIX version, but which are not guarded. I. e., the sem_xxx functions manipulating POSIX semaphores. Those don't need aguard, because they have been introduced in conjunction with their own header, i. e., semaphore.h. In these cases, the already existing ones still don't need a guard, just APIs added to the header will get the new _POSIX_C_SOURCE test. I think... Corinna > > > Yaakov? Does that make sense? > > > Thanks, > Corinna