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: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Fri, 11 Apr 2025 16:11:32 +0200
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <vtb7ul$1plb2$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <20250407210248.00006457@yahoo.com>
 <vt15lq$bjs0$3@dont-email.me> <vt2lp6$1qtjd$1@dont-email.me>
 <vt31m5$2513i$1@dont-email.me> <vt3d4g$2djqe$1@dont-email.me>
 <vt3iqh$2ka99$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 11 Apr 2025 16:11:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="414a89bbcf5f663aa3944451ac130353";
	logging-data="1889634"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/9WgMR3EJD2Qpen1ojyU/kuaBYqd9FTVc="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:YtzvBDLOsfkeb7IMW0nED32hDKM=
Content-Language: en-GB
In-Reply-To: <20250411142636.00006c00@yahoo.com>
Bytes: 3707

On 11/04/2025 13:26, Michael S wrote:
> On Thu, 10 Apr 2025 17:59:15 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
>>
>> An understanding of what "compatible types" means.
> 
> Bart didn't say that types are compatible or non-compatible.
> He said that they are 'compatible enough'. That is not terminology of C
> Standard, but terminology of his own. And he seems to understand it.
> 
> In my own translation, 'compatible enough' means that when these structs
> are accessed then any sane or even semi-sane compiler will generate code
> that will have the same effect as in case of access through structures
> with literally identical declarations.
> 

With that kind of thing, you always have to consider future-proofing for 
more advanced compilers.

With separately compile units that are then linked with a traditional 
linker, the compiler has no information about the details of struct 
definitions in different units.  Thus you can be sure that it everything 
will work even if the two different structs are defined with different 
tags and field names - indeed, as long as you stick to a common prefix 
with fields with the same representation and alignments, I have great 
difficulty imagining how it might possible fail to work just as if the 
struct types had actually been compatible.

However, compilers don't have to work that way.  Once you introduce 
link-time optimisation or other whole-program analysis, or compile the 
two units in one compile command, or allow more advanced object file 
formats that pass type details on to the linker, such assumptions don't 
hold.  A compiler with LTO can quite reasonably optimise code on the 
assumption that a pointer to one type could not alias a pointer to an 
incompatible type, even if those types were otherwise extremely similar.