From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 5F3DA3848016 for ; Thu, 22 Jul 2021 05:14:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5F3DA3848016 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-ot1-x32b.google.com with SMTP id j1-20020a0568302701b02904d1f8b9db81so4194279otu.12 for ; Wed, 21 Jul 2021 22:14:46 -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=7mlkE8w87BOeUzdhaAhV70+C7tm/iU+Z91tNVXqEssw=; b=DZ2Tg6QpGWjozr4fZHyMSkkBEuYX2GUPRh+/9k7ymGsKsFtkDSwcXA4PTLaEP70uWu aouDxaSVEPJq5XWS26x1R3Mz4Pi18NEzXjFlE6B2yN6l64OabWp6dwx2yWBlpp8MjTTE SpwvRqCT2A4XOksGxw+DJ8k0VWYMrKwmcYIW3g5qh6k0s43OydkR4G5MIZ9TRk0wGHYK k+Ny77zl455Dzg4cV4IUQeYX8D+HH60UisChl5WzV/09ROMFFogZ3nbr+Y7hEcEjifVk bQnC5iMfsag9svYjLpU0UweI3Cl4a/Q1ouBXtTA5PoNbfwszF6+UyDojEX5xphwxze8q UYQA== 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=7mlkE8w87BOeUzdhaAhV70+C7tm/iU+Z91tNVXqEssw=; b=Vgg8nruvr9s0p6fN1ic3kKMhIZ9TLZe7KPw5UZx9DXB896lSlbgEVSmk/1Yprcov1x NVkvNco/UrpGSSXoqS8F/Wx7aU7x7WuNzmgzkyA+Xg4BETVaET6vAvwLtwVzKQLEEzf/ wJhimk9UYNQCQ9fQygxa6xM+980GKLPE16UcQu13pJMsrvZiVjWfyxeAjl8OBnabXCM7 FV/PycwT5M3D41P2WUOxi2Glji2kvVXNNdanIuF2kEkRSveP+O4kAtvXzUAs3JdW/EZ6 LdoxZdiRo1SYi9dRqNfFz7NHn/u5B1HHPJzkMEPO7qP02Jyci/bP65cDkItdBoR2Wr6d LOGQ== X-Gm-Message-State: AOAM533ISXg5St+Nv3Bhlj7qEwpCcgzB00OGCnw8DPpzU4ClIJVUPskI 5t9MupT2fXYTS1DJNqmGhBiYz+JIcouOa1VXWAOasvzXQy2R X-Google-Smtp-Source: ABdhPJzfivj8jeFouD6bDxsBCFQ6bBeRqG0ola3RwdpR0uU0lKMBeElFh/s/XPHHdNt4SmDctSLJDt8j+1Al1ZvX62Q= X-Received: by 2002:a05:6830:40ae:: with SMTP id x46mr15253891ott.71.1626930885472; Wed, 21 Jul 2021 22:14:45 -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: Thu, 22 Jul 2021 07:14:34 +0200 Message-ID: Subject: Re: [PATCH 1/1] libc: Added implementations and prototypes for To: Newlib , Joel Sherrill , Matt Joyce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.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: Thu, 22 Jul 2021 05:14:48 -0000 Hi Corinna, I've made the changes you recommended but I'm running into a problem with the definition of SIG2STR_MAX. You suggested: #if __STDINT_EXP(INT_MAX) > 0x7fff #define SIG2STR_MAX (sizeof ("RTMAX+") + sizeof ("4294967295") - 1) #else #define SIG2STR_MAX (sizeof ("RTMAX+") + sizeof ("65535") - 1) #endif I've tried it both in newlib and natively but I get the error: " missing binary operator before token '(' " (In the first line of the block) At first I thought it might be a problem with using 'sizeof' in the definition. But I get the same error even if I hard-code the define values after #if __STDINT_EXP.... Could you please advise on what I might be doing wrong? Completely hard coding the value as 16 (the length of the larger string) works without error. Thank you very much for your time! 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 >