https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
Daniel Lundin <daniel.lundin.mail at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.lundin.mail at gmail dot co | |m --- Comment #19 from Daniel Lundin <daniel.lundin.mail at gmail dot com> --- This ought to be discussed again. "clang allows it" is not an argument. First of all, it is questionable if gcc is still conforming after the change discussed here and implemented as per gcc 8.0. Yes "an implementation may accept other forms of constant expressions" but that doesn't mean that a compiler is allowed to ignore the constraints in C17 6.7.9/4 nor the definition of an integer constant expression. So this ought to explicitly be a compiler extension and we ought to have a way to reliably compile strictly conforming programs with gcc without constraint violations silently getting ignored. So if this feature is desired as an extension (I'm sure it is), then the old diagnostic message should still be there when compiling as -std=c17 -pedantic. See detailed discussion and relevant ISO 9899 quotes here: https://stackoverflow.com/questions/68252570/why-are-const-qualified-variables-accepted-as-initializers-on-gcc On top of that mess, I just found out that gcc behaves inconsistently in regards of constant expressions between compiler ports. All gcc ports reject an initializer such as (uint32_t)&function_pointer as they ought, except gcc for ARM32 which silently allows this even under strict mode. This as per https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108875 which I think is NOT a bug, since the definition of an arithmetic constant expression (6.6) always had "Cast operators in an arithmetic constant expression shall only convert arithmetic types to arithmetic types". A function/object pointer is not an arithmetic type. A normative "shall" was violated. A conforming compiler must issue a diagnostic. If the C standard by design blocks meaningful use of some constant expressions inside initializer lists (I would agree that it does, the linked bug report above is a very valid use-case in embedded systems), then gcc has the option to make an extension and only warn in -pedantic mode. Bug again, this route was not taken there either. Standard compliance was just silently abandoned in the ARM32 port. Therefore the current state of affairs is: gcc <8.0 (IMO compliant) behaves differently from gcc >=8.0 which in turn behaves differently from gcc ARM32 any version. Three different gcc behaviors for a language feature which has NOT changed at all between C90 to C17. All of this has to be revisited for the C23 constexpr/"named constants" implementation, so it would be great if we at the same time can separate non-standard extensions from -pedantic mode. Notably C23 does not allow casts from non-arithemtic types inside arithmetic constant expressions either. Also note that C23 changed the wording slightly from C17: "An implementation may accept other forms of constant expressions; however, they are not an integer constant expression." I don't know why but likely because of some implemented DR.