Deutsch   English   Français   Italiano  
<87ecwt37b9.fsf@nosuchdomain.example.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Mon, 12 May 2025 13:25:30 -0700
Organization: None to speak of
Lines: 41
Message-ID: <87ecwt37b9.fsf@nosuchdomain.example.com>
References: <vspbjh$8dvd$1@dont-email.me> <868qoaeezc.fsf@linuxsc.com>
	<vt3oeo$2oq3p$1@dont-email.me> <86mscqcpy1.fsf@linuxsc.com>
	<vt48go$35hh3$2@dont-email.me> <86iknecjz8.fsf@linuxsc.com>
	<vt4del$3a9sk$1@dont-email.me> <86o6x5at05.fsf@linuxsc.com>
	<vt712u$1m84p$1@dont-email.me> <20250409170901.947@kylheku.com>
	<vt88bk$2rv8r$1@dont-email.me>
	<87wmbs45oa.fsf@nosuchdomain.example.com>
	<vt8hdp$333f0$1@dont-email.me>
	<87semf4pw5.fsf@nosuchdomain.example.com>
	<vt9let$4au3$1@dont-email.me>
	<87zfgn344c.fsf@nosuchdomain.example.com>
	<20250411142636.00006c00@yahoo.com> <20250411102119.431@kylheku.com>
	<20250413204521.0000238e@yahoo.com> <861psuziq2.fsf@linuxsc.com>
	<vvt13g$14otk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 12 May 2025 22:25:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ec3410180c1ee7cec196ae011e16bd7a";
	logging-data="1352697"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/eDqhzKHjIVmqf9VOKX0R0"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:qwGLj74KcAgPq5XW+7MHDRzuVzk=
	sha1:009sGhkCUlIukU1+vhpFH82VmC8=
Bytes: 3772

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 */