Re: [PATCH 1/1] libc: Added implementations and prototypes for

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 <[email protected]> wrote:
>
> On Jul 19 08:19, Joel Sherrill wrote:
> > On Mon, Jul 19, 2021 at 4:48 AM Corinna Vinschen <[email protected]> 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
>