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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net