On Wed, May 11, 2022 at 8:40 AM Rob Landley <r...@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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net