[Toybox] __attribute__((__noreturn__)) vs _Noreturn

[Rob Landley]

On 5/12/22 12:26, enh wrote:
> 
> 
> On Thu, May 12, 2022 at 9:56 AM Rob Landley <rob at landley.net
> <mailto:rob at landley.net>> wrote:
> 
>     On 5/11/22 11:10, enh wrote:
>     >> 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.)
> 
>     I can move from 7 years to 10 if there's specific demand for it,  but 7 was
>     based on a lot of experience and a certain amount of research. It's enough
>     Moore's Law half lives to get you down to about 2% of the installed base, but
>     it's ALSO where expertise in the old stuff seems to drop out of living memory.
> 
> 
> (i think i've said before, but _our_ plan is to ditch glibc for musl on the
> host, so we can just statically link and forget about _libc_ problems. what i
> don't know [because historically we've used glibc] is the extent to which these
> kinds of users are relying on glibc trying to work around missing stuff on old
> kernels. aiui glibc pretty much always tries, musl tries in some cases, and
> bionic basically never tries.

I'm pretty sure the "old kernel" workarounds musl doesn't do are mostly things
that predate 3.0. (That's what
https://wiki.musl-libc.org/supported-platforms.html says anyway, I'm not sure
how up to date it is but Rich would know.)

Given that 3.0 came out in 2011 and is thus past even the TEN year support
horizon, I suspect you're good. :)

P.S. I broke down and added
https://landley.net/toybox/downloads/binaries/toolchains/latest/ to the nav bar
on the left in the toybox page. "Downloads->compilers".

I have an LLVM hexagon build, but don't have generic LLVM builds for the other
targets because the libgcc replacement in the LLVM build is a giant steaming
pile of special cases that doesn't want to build in a remotely generic way. I
got it to work for hexagon by picking apart the toolchain build qualcomm added
to the qemu test suite, but couldn't manage to genericize it to the other targets...

> so there might be some fallout there still, but i
> have no data yet. given that linux is free, kernel vulnerabilities are rife, and
> most modern hardware supports virtualization, i'm not _super_ sympathetic to
> running old software. i have a lot more sympathy for running old hardware, but
> as someone who's running current ubuntu on an 11 year old laptop ... i'm

Mine's from 2012.

> unconvinced i'm actually _helping_ people by making it easier to stay on
> ridiculously old versions of linux. 7 years is more than enough.)

Musl theoretically supports 3.0, which is as old as your laptop.

>     The old "mirror being 7 years bad luck" was from medieval observations about
>     people recovering from old traumas, changing behavior, and moving on with their
>     lives: that's approximately the time it takes a socializing group of humans to
>     collectively stop reacting to a cause that's no longer present. From a technical
>     perspective, it means past that point the relevant domain experts are no longer
>     immediately available. People can dig up and recreate the old ways if you track
>     down an ex-expert willing to put in some time, but most of them won't have the
>     answers off the top of their head anymore. They've stopped exercising it,
>     nobody's regression testing it, have to dig something out out of a box...
> 
> yeah, testing's hard enough already without saying "any version of any distro
> shipped in the last 10 years"!

I've installed weird things like "PC Linux OS" under kvm to reproduce people's
issues, but it's nice to have SOME constraints...

>     I suspect it would work if I said "gnu99" instead of "c99", but that defeats the
>     purpose of the exercise. (The gnu guys keep forcing you to #define gnu to get
>     wrappers for Linux system calls that the kernel guys introduced, like "man 2
>     unshare". It has nothing whatsoever to do with gnu, never did, but the glibc
>     guys are political propagandists.)
> 
> (to be fair, gnu11 and gnu++14 are the _gcc_ political propagandists, not glibc
> :-) )

Yes and no:

https://web.archive.org/web/20080213230249/http://sources.redhat.com/ml/libc-announce/2001/msg00000.html#:~:text=Stallman

They're a lot less bad about it than they used to be, but historically?

The FSF welcomed Stallman back after his Me-too-ing. They're fundamentally
incapable of moving beyond him.

> and, yeah, today's current gcc and clang both default to "gnu17" for C.

Was there anything in c17 worth knowing about? Looks like typo correction and
they deprected ATOMIC_VAR_INIT.


>     Toolchain version upgrades break stuff. This is sadly not avoidable. The 7 year
>     horizon thing gives people time to adapt, but anybody who adds -Werror to their
>     build scripts voluntarily gives up the right to complain about "apt-get update
>     du jour broke my build" happening at least annually, let alone major version
>     upgrades that swap --std defaults...
> 
> (unfortunately, the people who add -Werror to their build flags do not believe
> that. things like -Wall are worse, because that set changes over time, and if
> you're using -Werror, you just made that the problem of the toolchain team
> who're just trying to upgrade the compiler...)

I've got -Wall but not -Werror, and I whack-a-mole -Wno-stupid-thing and
-fno-stupid-thing all the time. (Luckily gcc no longer warns "unrecognized
-Wno-stupid-thing" unless it's already producing other warnings. As far as I
know, llvm categorically treats -fno-thing-I-was-not-doing and
-Wno-thing-I-was-not-doing as ingnorable, which SEEMS OBVIOUS, and yet...)

Unfortunately, as with -O2 or -Os, there's no obvious way to switch the
individual things on when it's NOT in large batches like that. And without
-Wall, it doesn't really warn about anything. I haven't got a suggestion to
improve that, seems a hard UI design issue. :(

Rob