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

[Matthew Joyce]

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 <vinschen@redhat.com> wrote:
>
> On Jul 19 08:19, Joel Sherrill wrote:
> > On Mon, Jul 19, 2021 at 4:48 AM Corinna Vinschen <vinschen@redhat.com> 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
>