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 16ED33951C0E for ; Mon, 19 Jul 2021 14:31:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 16ED33951C0E 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=1626705083; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ZsgAG7GIIrtOwSkO0H3AkeIdXnLHbbALCzmwLu5Y9h0=; b=JQSmnZn6jff3xYXMuWO4G6R0IXe+0EBVSQQes4i+tsmle1VlS/uTJBX3AofL5Da+dDrqyJ 8v37QoEatV3upIYfGsfFA2WuRI7rq7xhXAdS801QJKtivj/1wohGM+Yg8o4TT35YtmKHP2 gps6OzIFJ/sNg+tMTaOFvxS5rzqKDuk= 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-52-7KaW2qf1No28kM_Zu3XU1g-1; Mon, 19 Jul 2021 10:31:20 -0400 X-MC-Unique: 7KaW2qf1No28kM_Zu3XU1g-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 794DC50756; Mon, 19 Jul 2021 14:31:19 +0000 (UTC) Received: from calimero.vinschen.de (ovpn-113-186.ams2.redhat.com [10.36.113.186]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 365EB60C82; Mon, 19 Jul 2021 14:31:18 +0000 (UTC) Received: by calimero.vinschen.de (Postfix, from userid 500) id A1414A807A5; Mon, 19 Jul 2021 16:31:16 +0200 (CEST) Date: Mon, 19 Jul 2021 16:31:16 +0200 From: Corinna Vinschen To: Joel Sherrill Cc: Newlib , Matt Joyce Subject: Re: [PATCH 1/1] libc: Added implementations and prototypes for Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: Joel Sherrill , Newlib , Matt Joyce References: <20210717101038.3283-1-mfjoyce2004@gmail.com> <20210717101038.3283-2-mfjoyce2004@gmail.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.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: Mon, 19 Jul 2021 14:31:25 -0000 On Jul 19 08:19, Joel Sherrill wrote: > On Mon, Jul 19, 2021 at 4:48 AM Corinna Vinschen wrote: > > #if __STDINT_EXP(INT_MAX) > 0x7fff > > #define SIG2STR_MAX (sizeof ("RTMAX+") + sizeof ("4294967295") - 1) > > #else > > #define SIG2STR_MAX (sizeof ("RTMAX+") + sizeof ("65535") - 1) > > #endif > > Just checking here about the terminating NUL. The sizeof("RTMAX+") includes > a NUL so the -1 at the end of the expression subtracts the one from the > sizeof("NUM"). Is that right? > > An off by one error here would be hard to catch if it slipped through. Writing a simple test program and attaching it to the patchset would be a good idea anyway. > > This is not entirely correct. The POSIX draft requires the signal > > string to be returned for RT signals to be expressed as either "RTMIN+x" > > and "RTMAX-x", dependent on the signal number. Please see > > https://www.opengroup.org/austin/docs/austin_1110.pdf, page 85, the two > > paragraphs starting at line 61678 (unfortunately copy/paste from this > > doc doesn't work nicely). > > He implemented it this way initially but it looks like I optimistically misread > "the paragraph at line 61681 which gives an option on how to do the upper > half of the RT signals and thought/hoped it let the code have to produce > one format. But reading it again, there is a clear qualifier: > > "If signum is between (SIGRTMIN+SIGRTMAX)/2 + 1 and SIGRTMAX−1 > inclusive, ..." But then again... ...on rereading the text it appears the intention was to allow both ways of expressing the signal, whichever is preferred by the implementation. Checking gnulib, they use RTMAX-x for the upper half of the range. The Oracle website expresses it in terms of 8 RT sigs and claims For access to the signals in the range SIGRTMIN to SIGRTMAX, the first four signals match the strings "RTMIN", "RTMIN+1", "RTMIN+2", and "RTMIN+3" and the last four match the strings "RTMAX-3", "RTMAX-2", "RTMAX-1", and "RTMAX". So it looks like there's some kind of consensus to do it that way. I guess we should follow suit. > > We have a special problem here. i686 Cygwin only supports a single RT > > signal. For historical reasons, don't ask. > > > > I. e., SIGRTMIN == SIGRTMAX. This special case should be checked here, > > to make sure the code works with this very special, very non-POSIX > > behaviour. I think the easiest way to handle that is to skip the > > entire "RTMIN+"/"RTMAX-" code if SIGRTMIN == SIGRTMAX. There just is > > no such valid value in this case. > > Do I interpret this as adding a conditionally compiled block to handle the > special case when SIGRTMIN == SIGRTMAX? Just skip the RT sigs handling code block. > Is it possible for a target OS not to define any real-time signals? For bare-metal and embedded targets it's probably a good idea to assume just that. Per POSIX, 4 RT sigs are required, but that's often no concern for small targets, and for i686 Cygwin we simply screwed up. Corinna