Groups | Search | Server Info | Login | Register

Groups > comp.lang.c > #393359

Re: do { quit; } else { }

Show all headers | View raw

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.com
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-11 19:05 -0700
  Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-12 16:37 +0200
    Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-12 13:25 -0700
      Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-13 11:40 +0200
        Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-13 20:17 -0400
          Re: do { quit; } else { } Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-13 17:51 -0700
            Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-13 22:23 -0400
              Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-14 11:07 +0200
                Re: do { quit; } else { } Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-14 15:03 +0000
                Re: do { quit; } else { } James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-14 23:17 -0400
            Re: do { quit; } else { } David Brown <david.brown@hesbynett.no> - 2025-05-14 11:22 +0200
          Re: do { quit; } else { } Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-13 18:15 -0700

csiph-web