Re: [C PATCH, v2] Fix for redeclared enumerator initialized with different type [PR115109]

[Martin Uecker <uecker@tugraz.at>]

Am Montag, dem 20.05.2024 um 21:30 +0000 schrieb Joseph Myers:
> On Sun, 19 May 2024, Martin Uecker wrote:
> 
> >     c23 specifies that the type of a redeclared enumerator is the one of the
> >     previous declaration.  Convert initializers with different type accordingly
> >     and add -Woverflow warning.
> 
> It doesn't make sense to use -Woverflow.  Either the value is the same (in 
> which case it fits in the desired type), or it's different (and you should 
> get the "conflicting redeclaration of enumerator" error or some equivalent 
> error, whether or not the value in the redeclaration fits in the previous 
> type).
> 
> Note that this includes both explicit values and values determined by 
> adding 1 implicitly.  E.g.
> 
>   enum e { A = 0, B = UINT_MAX };
>   enum e { B = UINT_MAX, A };
> 
> is not valid, because in the redefinition, A gets the value 1 greater than 
> UINT_MAX (which is not representable in unsigned int) - there is *not* an 
> addition in type unsigned int, or in type enum e.
> 
> The constraint violated is the general one "If an identifier has no 
> linkage, there shall be no more than one declaration of the identifier (in 
> a declarator or type specifier) with the same scope and in the same name 
> space, except that: ... enumeration constants and tags may be redeclared 
> as specified in 6.7.3.3 and 6.7.3.4, respectively." (where 6.7.3.3 says 
> "Enumeration constants can be redefined in the same scope with the same 
> value as part of a redeclaration of the same enumerated type." - as the 
> redefinition is not with the same value, the "as specified in 6.7.3.3" is 
> not satisfied and so the general constraint against redeclarations with no 
> linkage applies).

This assumes that the value in question is the one of the initializer and not the
one after initialization (with no clear rules how this works in this case), 
which is probably not how this wording would be understood in other contexts.
But I agree that your interpretation is probably closer to what was intended
and makes more sense in this case.

Martin

>