From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) by sourceware.org (Postfix) with ESMTPS id AB3AC385840E for ; Tue, 20 Jul 2021 05:12:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AB3AC385840E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x235.google.com with SMTP id h9so23351943oih.4 for ; Mon, 19 Jul 2021 22:12:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=FZmmQwFN9IY4wqiJ1ZlLDk0vENACxumsfGTp7lAgICU=; b=NsxQGK/PYRY/H3J3jtlv/mXGr7empbD0EXopVDIs/lHfFq+ACXiFMqKHJoInJ8fjMy MfSKPl5e7LEd8qahnmwyFb6RrFMHW+Urxa1C6yGlBy0+0M5X6Ygz10Ory0rTAVdOZS9S I7anhAkI059DQozFDTqiPDtKzEaYnyVLMArTdgBQhhPHDGrJjT7AUxxykO5rUKgbmltG nkhMc3KCvrABKCIbNsBXAONrTPicASc+IdGvarHUeGFmIBROeDsWRQIB4gWyYOe1zgi9 li0O6LUub2RspHGGGi7Y9PSUgGuJ5/SxE0VAqIcuyH7QPlS0Qpq4/dPoDY4wAcNrLfnE AFSw== 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:from:date :message-id:subject:to:content-transfer-encoding; bh=FZmmQwFN9IY4wqiJ1ZlLDk0vENACxumsfGTp7lAgICU=; b=Og98I+mVyzRW0lAbl0BV5GUxvJQwdwRERJD/CUMfuy1r65lsQOQCw9hKlTs0lOM3oC PgnKmyRB931RiLUBv78Qaj/+Jo1Hn9s/8wZbCLOCYhUAM9Ku+sMEKR25db7c5C9phEnA MvcVqnEGT+5A+0K3BPKmDqAT9icosf5uahV2c0ARv7whV/ERth81VFedJ7lb/SrgGC56 BRJGqH1mNqf7IrMFSD/GCsLj8Tkg79mNydT9PR/ZVs1tlzd91cK3MKwIFZLQ+AkodK9Z RiOsGPfwkPK4HUxUi2zhtCs1kxXlnUk3YjO+KAaFUEj1P8D7lwRRoiEZDbIe7pMZkx05 Y0RQ== X-Gm-Message-State: AOAM533IdvZGztKBFu0Z/ZpUmAe5CFCChoK3O/BoDIE09hlo56Q6e9D8 HHE7bPEvWtg8kxvElyc4OeNV1dROtnErLOBSCg== X-Google-Smtp-Source: ABdhPJybO+U/uE5w5nDs9lr6M71/sk46LsZ4pYczvSAUbBmr9XjTlUOCzKvG8ka1j2mbSioIW0iyI+rkIp9KI6pCFUY= X-Received: by 2002:aca:ab16:: with SMTP id u22mr1188676oie.177.1626757928044; Mon, 19 Jul 2021 22:12:08 -0700 (PDT) MIME-Version: 1.0 References: <20210717101038.3283-1-mfjoyce2004@gmail.com> <20210717101038.3283-2-mfjoyce2004@gmail.com> In-Reply-To: From: Matthew Joyce Date: Tue, 20 Jul 2021 07:11:57 +0200 Message-ID: Subject: Re: [PATCH 1/1] libc: Added implementations and prototypes for To: Joel Sherrill , Newlib , Matt Joyce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: Tue, 20 Jul 2021 05:12:10 -0000 Hi Corinna, Thank you very much for the feedback! I'll make these changes as suggested after work today. Sincerely, Matt On Mon, Jul 19, 2021 at 4:31 PM Corinna Vinschen wrot= e: > > 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+") incl= udes > > 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 t= wo > > > 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 upp= er > > half of the RT signals and thought/hoped it let the code have to produc= e > > one format. But reading it again, there is a clear qualifier: > > > > "If signum is between (SIGRTMIN+SIGRTMAX)/2 + 1 and SIGRTMAX=E2=88=921 > > 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 R= T > > > signal. For historical reasons, don't ask. > > > > > > I. e., SIGRTMIN =3D=3D 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 =3D=3D SIGRTMAX. There jus= t 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 =3D=3D 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 >