Re: do { quit; } else { }

On 12/05/2025 22:25, Keith Thompson wrote:

David Brown <david.brown@hesbynett.no> writes:
[...]

For plain integer types, however, I think the argument for making
equal-sized types compatible is a lot stronger.  Some compilers
specifically say that they allow aliasing between such types (MSVC,
according to what I have read, have said they never intend to support
"strict aliasing" optimisations).  Many software projects (such as
Linux) use "-fno-strict-aliasing".  And countless C programmers
mistakenly believe that identically sized integer types are compatible
(though I am not advocating for a weaker language simply because some
users misunderstand the rules).

 I think that a lot of C programmers misunderstand what "compatible
types" means.  Many seem to think that two types are compatible if
they have the same representation and can be assigned without a cast.
 

Yes.  Basically, most C programmers are not particularly aware of the technical definitions of some of the terms in C standards where they differ from common usage.  The word "compatible" in English means that the things in question can work together or fit together.  Thus there are a number of ways to view types as "compatible" in C in normal English, but only one definition of "compatible type" as a specific term in the C standard.  (This sort of thing is, I think, inevitable in a language standard unless you want to invent new terms without a normal language meaning - such as "lvalue".)

In fact type compatibility is a much stricter concept than that.
Two types are compatible if they are *the same type*, and in a few
other circumstances.  For example, char, signed char, and unsigned
char are all incompatible with each other, even though two of them
are guaranteed to have the same representation.
 A good way to think about it is that pointers to two types can be
assigned without a cast if and only if the two types are compatible.
For example, int and long objects can be assigned to each other
without a cast, but int* and long* objects cannot.
 

Yes.  That is also a good way for people to check if types are compatible, if they want to use "try it on a compiler and see" as an aid.

And changing the language to make int and long conditionally
compatible would (a) make it too easy to write code that's valid
in one implementation but violates a constraint in another, and (b)
would break existing code.

Speaking as someone who uses the fixed-size types often, and sees it in other code, there is already a lot of such code that is valid in one implementation or target and not on others, primarily because "int32_t" may be typedef'ed to "int" or "long", and "int64_t" may be "long" or "long long".  But I can see that making "long" compatible to either "int" or "long long", according to implementation, might cause more issues.
I think a better change to consider is not changing the rules of type compatibility, but slightly loosening the rules for what types of lvalue expressions can be used to access objects in 6.5p7.  (It is possible this could be done by changing the "effective type" rules in 6.5p6, but that might be more complicated.)  Basically, we retain the restriction that an int* and a long* (for 32-bit int and long) cannot be assigned to each other without a cast, but that an int* lvalue /can/ be used to access a long object, and vice versa.  The same would apply to any pairs of scalar types that have identical values and representations.  I believe that change would not break any existing code, but would certainly fix some existing broken code.  And it would allow compilers to continue to use most "strict aliasing" optimisations.

 For example, a generic selection cannot
have two associations with compatible types.  _Generic with "int:"
and "long:" would become invalid for implementations that make int
and long compatible.
 

While that is true, I suspect that _Generic is used so little in practice that few if any would notice it!

(I wouldn't mind seeing a new form of generic association that
selects the *first* matching type, but that's another can of worms.)
 

If I were looking to improve _Generic, I'd want a way to add new types to an existing _Generic macro (for new overloads).  This could easily by done if the preprocessor had a #redefine directive that let you give a new definition of a macro name while using the old definition when expanding the new macro.  That would be a whole barrel of worms :-)