Hi Paul, > That reminds me, we're in a sticky situation about _Noreturn for another > reason. > > Draft C23 requires [[noreturn]] before "extern" and states that > _Noreturn is obsolescent. It's plausible that a future C version will > drop the requirement to support the _Noreturn keyword. If that happens, > "#define _Noreturn [[noreturn]]" won't be a valid workaround unless > people write "_Noreturn extern" instead of "extern _Noreturn", and > similarly for "_Noreturn static" etc. > > Should we change Gnulib code and put _Noreturn first in its declarations > now, proactively? This might help future-proof the code, and get people > used to putting directives first.
For the .h files, we have already started doing so, in order to maintain C++ compatibility: <https://lists.gnu.org/archive/html/bug-gnulib/2020-02/msg00008.html> For the other files, I suggest to wait until it becomes clear how ISO C will evolve in this aspect. They could un-obsolete the '_Noreturn' keyword. They could allow [[noreturn]] to be used before _or_ after the 'extern' or 'static' keyword. They could make other changes that I can't imagine. We have seen (with the K&R C declaration removal, as well as with %b and %B just last week) that the way the standard evolves is just unpredictable. When a new ISO C draft is in ballot phase, we still have a year or more of time to adapt our code. There's no pressure on us to do these things 2 or 10 years in advance. Bruno
