[Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/10/22 13:00, enh wrote:
> On Tue, May 10, 2022 at 10:44 AM Rob Landley <rob at landley.net> wrote:
>>
>> On 5/9/22 18:54, enh via Toybox wrote:
>> > i think this question already came up recently, but mainly as a joke
>> > before ... "how do you feel about C11?"
>>
>> It's comfortably past the 7 year support horizon. I haven't got anything against
>> C11, I just haven't needed anything from it yet?
>>
>> Actually, I think that typecast constant array syntax is from C11:
>>
>>   s = ((char *[]){"NICE", "SCHED", "ETIME", "PCPU", "VSIZE", "UNAME"})[k];
> 
> my personal favorite is `struct type var = { .one_thing_i_care_about =
> 123 };` with everything else guaranteed zeroed.

Yup, I've been depending on that too.

>> So yeah, we may already be depending on it and I should update the design.html
>> page...
>>
>> > because i actually have a specific reason to want it now. (buckle in,
>> > because this is going to annoy you...)
>> >
>> > we'd seen large numbers of native crashes show up from toybox, and
>> > oddly they were from the toybox _tests_. which is weird, because we'd
>> > have expected the tests to _fail_ in that case, and such a problem not
>> > to get checked in.
>> >
>> > (so, long-term question: should/can we improve the test suite to spot
>> > exit-via-signal and automatically make that a FAIL?)
>>
>> I thought it already did ? runtest.sh line 140:
>>
>>   # Catch segfaults
>>   [ $RETVAL -gt 128 ] && [ $RETVAL -lt 255 ] &&
>>     echo "exited with signal (or returned $RETVAL)" >> actual
>>
>> This replaces the output it's comparing with "exited with signal..." which
>> should never match the real output, and should be printed in the diff.
> 
> /me checks...
> 
> ah, yeah, the trouble was it was the common pattern of a test that
> says `command || ...` or `command && ...` which doesn't have a third
> case of "but die completely if it was > 128".

Alas, only so much I can do in the plumbing. :(

The fact that || hides segfaults is something to ponder in test design. Shell
intercepts the failure and discards failure type. Yeah, that's what we asked it
to do. Hmmm...

Maybe something like having CONFIG_DEBUG replace all the default signal handlers
with:

  dprintf(2, "AAAAAAAAHHHHHHH!!!!!!!!"); _exit(128+signal);

Except I would be loathe to ship that, and you enable CONFIG_DEBUG by default,
and if I made it CONFIG_MORE_DEBUG you'd just enable that.. (Which is GOING to
cause false positive problems. Remember sigpipe. Nevertheless, it is a thing we
COULD do to catch this sort of thing. It WILL cause false positive issues though.)

>> *shrug* I've done uglier things with a similar commit comment. "Here's why this
>> is ugly: it's working around a compiler bug." Ok then.
> 
> yeah, pretty much. (obviously another alternative is "i revert the
> change that tickled this locally in T, and we worry about a proper fix
> for U", but given that this still isn't fixed upstream yet, others
> might hit it too.)
> 
> plus i actually like some of the other C11 stuff, so even though this
> is a _stupid_ forcing function, i'm not unhappy to have _a_ forcing
> function :-)
> 
> (if i didn't already say, my reasoning for moving the AOSP default to
> C11 for U is that i feel like we're at the tipping point now where
> "even C programmers", not known for their love of the new, are
> starting to _assume_ C11, and we're having more and more people have
> to manually opt in/ask why stuff doesn't "just work". linux moving
> will probably be quite a heavy thumb on that side of the scale. and in
> the C committee's defense [in contrast to the C++ committee], they're
> pretty good about not breaking stuff. literally the only problems i've
> seen have been from people who had untested and incorrect code in #ifs
> that checked for C11...)

C11 has leaked in over t he past 2-3 years. Time to update the docs and
acknowledge it...

> but, yeah, this kind of "codegen bug specific to one architecture" was
> the kind of GCC nonsense i thought LLVM's cleaner design was supposed
> to save us from :-(

It's written in C++ and you consider it cleaner?

> (to be fair, i _do_ see a lot less of this with LLVM than i used to with GCC.)

I expect that's more "lack of FSF" than anything else. And scaling 50% more buys
you one iteration of Gates' Law if you're lucky. Code complexity expands to fit
available management capability if you let it.

(David Graeber liked to explain how most work is maintenance by saying you make
a cup once but wash it a thousand times. I spend most of my effort performing
code topiary trying to make a bonsai command line by constantly PRUNING this
crap. I wanted somebody to do a proper version of Fabrice Bellad's tinycc for
similar reasons: so we have a comprehensible reference implementation everyone
can understand and regression test against. Alas, that concept only ever worked
for C, not for C++. C is not a moving target, and the whole language can be
explained in an hour.)

>> Rob

Still Rob