[Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

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

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?

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

> 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

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.

Rob