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

[Matthew Joyce <mfjoyce2004@gmail.com>]

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 <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
>