[PATCH 1/1] libc: Added implementations and prototypes for
Tue Jul 20 05:11:57 GMT 2021
Thank you very much for the feedback! I'll make these changes as
suggested after work today.
On Mon, Jul 19, 2021 at 4:31 PM Corinna Vinschen <email@example.com> wrote:
> On Jul 19 08:19, Joel Sherrill wrote:
> > On Mon, Jul 19, 2021 at 4:48 AM Corinna Vinschen <firstname.lastname@example.org> 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.
More information about the Newlib