[Toybox] [PATCH] timeout.c: fix for macOS.

[enh]

On Thu, Aug 25, 2022 at 3:24 AM Rob Landley <rob at landley.net> wrote:

> On 8/24/22 19:31, enh via Toybox wrote:
> > I don't know why we get away with this on Linux, but macOS really
> > means business with the "values of objects of automatic storage
> > invocation duration that do not have the volatile type and have
> > been changed between the setjmp() invocation and longjmp() call are
> > indeterminate" thing, leading to bad fds and a bad pid.
>
> Their setjmp() isn't annotated with attribute((__returns_twice__)). Musl
> had
> that problem with vfork() once upon a time. Rich fixed it:
>
>   https://landley.net/notes-2017.html#03-02-2017


checking the setjmp.h on this mac i see that you're right. we found and
fixed that in bionic long enough ago i'd forgotten about it. but
double-checking just now, i see we didn't do it for sigsetjmp()...

/facepalm


> Sigh. Applied. (And then I patched on top if it because TT starts zeroed
> so you
> don't need to set fd[0] to 0. Don't think I broke anything but can't test
> mac.)
>

yeah, ToT still works for me. thanks!


> > Using
> > volatile causes lots of warnings about passing `volatile int*`
> > instead of `int*`, so it's a smaller change to move the fields into
> > TT (and avoid the "automatic storage" part) than it is to add the
> > `volatile` modifier.
> >
> > Four timeout tests fail on macOS (both locally and on github's CI)
> > without this patch, and all timeout tests pass on macOS with this
> > patch.
>
> Got it. I still consider this a mac bug, but technically it's "lack of
> longstanding gcc extension use in their libc". Roughly on the level of not
> having the empty (x ? : y) extension...
>

i'd file a bug against apple, but my experience has been that they never
look at a bug, and just close everything out once a year when they ship a
new release without having run your repro case (but if someone else wants
to...).


> (Someday, the C standards committee may catch up, but I expect Planck's
> principle to be involved if so.)
>
> Rob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20220825/666bfac6/attachment.htm>