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.
