[parted-devel] GCC unhappy with "case PED_EXCEPTION_OK_CANCEL:"

[D. Hugh Redelmeier]

| From: Brian C. Lane <bcl at redhat.com>

| Thanks for the patch, but I'm undecided as to whether this is better. I
| almost feel like this is a gcc problem -- it knows about the enum, and
| it knows the defines combining the enum values are using them, so it
| ought to (in my ideal world) figure it out.
| 
| But I'm open to hear what others think.

The same warning is issued by clang.  So this is not just making gcc 
happy.

This is a fine point of C that isn't really resolved as far as I know.

The change I proposed certainly is legal C and I think that it is actually 
clearer than the old code.

Now, for some C lawyering. I'm using the final draft of the standard 
before C11 (that's what I have at hand).

In section 6.7.2.2 "Enumeration Specifiers", in "Semantics", paragraph 4 
says:

  Each enumerated type shall be compatible with char, a signed integer 
  type, or an unsigned integer type. The choice of type is 
  implementation-defined, 128) but shall be capable of representing the 
  values of all the members of the enumeration.

This says that the storage must be capable of representing each member of 
the enumeration.  It does not say that any value not a member can be 
represented.  Your macros create values that are not members.

On the other hand, on a two's complement machine, enum storage can 
represent any ORing of enum members.  But not, for example, every summing.

On a one's complement machine, ~0 == 0, which causes some ORings to not 
work as expected.  One's complement machines seem to have disappeared, but 
C11 supported them.

In Annex I (informative) "Common Warnings", paragraph 2 lists

  A value is given to an object of an enumerated type other than by
  assignment of an enumeration constant that is a member of that type,
  or an enumeration object that has the same type, or the value of a
  function that returns the same enumerated type (6.7.2.2)

Note: this is not "normative", just "informative".  But it shows that
the Committee considers this warning reasonable.


I think that stylistically the change I proposed is an improvement:

- only members of the enumeration will be assigned to object of the 
  enumeration type

- everything with a name PED_EXCEPTION_* is defined in one way
  (as an enumeration constant)

- C macros are powerful magic and should be reserved for magical purposes

- it makes GCC an CLANG happy.

[It took a lot longer to research this message than to create the patch!  
Even so, I appreciate the care you exercise in adopting patches.]