[Toybox] __attribute__((__noreturn__)) vs _Noreturn

[enh]

On Wed, May 11, 2022 at 8:40 AM Rob Landley <rob at landley.net> wrote:
>
> On 5/10/22 17:08, enh wrote:
> > attached two separate patches; one to move, the other to take
> > advantage of the move.
>
> I'm reluctant to specify --std= because I've never had to before. When I started
> using c99 I didn't have to specify --std=c99, and we've leaked c11 features into
> the thing already and the build didn't break with the compiler defaults. I.E.
> the compiler defaults shifted long before we did, including the oldest versions
> I regression tested against. When did gcc move to c11 by default... Looks like
> it was in 5.1.0, which came out in 2015:
>
> https://gcc.gnu.org/onlinedocs/gcc-5.1.0/gcc/Standards.html
>
> Which was 7 years ago. They have since moved on to 2017 which I didn't even know
> was a thing?
>
> #define __STDC_VERSION__ 201710L

yeah, noticing that for both compilers was another "yeah, maybe it's
time to stop artificially holding android's default back"...

> Now in theory sufficiently old versions of centos would have the "centos people
> taking advantage of Red hat's 10 year paid support horizon" thing? Sigh, what is
> the oldest version of that still supported...
>
> https://www.zdnet.com/article/centos-linux-8-is-about-to-die-what-do-you-do-next/
>
> The next version of centos does not exist. Apparently Centos has completely gone
> away. Right, I can stop caring about it then I guess?

(that was my reaction to the recent news, yes. "fine by me", since
centos was _always_ the most problematic distro to support, probably
because it naturally attracted the kinds of folks who _wanted_ to run
stuff from a decade ago.)

> If this does actually break somebody, I can have portability.h do:
> #if version < thingy
> #define _Noreturn __attribute__((__noreturn__))
> #endif
>
> But I'd rather wait for a complaint?
>
> (Also, when I try to build older versions with CFLAGS=--std=c99 to see where c11
> leaked in, even 0.8.0 won't build because of random failures like
> CLOCK_MONOTONIC isn't defined? Looks like gcc/glibc is being intentionally
> obstructive again. I'd rather not micromanage this the same way I refuse to
> #define gnu to get stuff out of the headers: that way lies madness...)

interesting, i don't see that for the android build, but maybe we just
don't build that stuff for the host. (bionic's always [well, "since i
inherited it"] taken the attitude that you get all the things, all the
time. there's very little [though admittedly non-zero] value to being
able to fine-tune your standard version, but that's _far_ too
confusing for most developers. "it just works" minimizes our support
burden, and we have an orthogonal "what version of Android do you want
this to _run_ on?" problem that's more than enough cognitive load for
everyone.)

> > given that `_Noreturn` is required to be at the start, i kind of wish
> > they'd made it imply `void`; `noreturn void` seems a bit redundant!
>
> stdnoreturn.h does literally nothing except #define noreturn _Noreturn

yeah, but like i said yesterday --- that's how you have your "sensible
keyword [noreturn]" cake and also eat "don't break existing code
[no-one's using _Noreturn]". if you look at the git history _for
toybox_ you can see that Apple's *headers* were already using
`noreturn`, and that's why toybox had to have
__attribute__((__noreturn__)) rather than __attribute__((noreturn))
:-)

> That's a sad, pathetic excuse for a header. As silly a _Noreturn is it's no
> sillier than __attribute__(thingy) so I think I'd rather just use the actual
> name directly. I could #define it myself if I wanted to, just as I could #define
> { BEGIN and } END like the pascal guys did long ago. Not going there. Yes it's a
> stupid name, but the wrapper isn't LESS stupid, and doesn't FIX anything.

(and your own #define could always include the obligatory `void` :-) )

> Rob