Sujet : Re: do { quit; } else { }
De : Keith.S.Thompson+u (at) *nospam* gmail.com (Keith Thompson)
Groupes : comp.lang.cDate : 12. May 2025, 21:25:30
Autres entêtes
Organisation : None to speak of
Message-ID : <87ecwt37b9.fsf@nosuchdomain.example.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
User-Agent : Gnus/5.13 (Gnus v5.13)
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.
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.
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. 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.
(I wouldn't mind seeing a new form of generic association that
selects the *first* matching type, but that's another can of worms.)
-- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.comvoid Void(void) { Void(); } /* The recursive call of the void */