Path: ...!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: Endless complaints [was Re: do { quit; } else { }]
Date: Fri, 11 Apr 2025 15:02:42 +0200
Organization: A noiseless patient Spider
Lines: 116
Message-ID: <vtb3ti$1i742$1@dont-email.me>
References: <vspbjh$8dvd$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> <eFQJP.51897$j2D.28734@fx09.iad>
 <vt8n5k$385mm$1@dont-email.me> <vt9g3b$3v929$1@dont-email.me>
 <vt9j4j$1rdm$2@dont-email.me> <vtaj0f$11tb7$1@dont-email.me>
 <vtaukr$1dp7m$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 11 Apr 2025 15:02:43 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="414a89bbcf5f663aa3944451ac130353";
	logging-data="1645698"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+oJJVFtTC/zZaLDSjPXjrvU0LVoZGddF4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:zpCiLEp3fWeCmUUOoWVlt9OfYz4=
In-Reply-To: <vtaukr$1dp7m$2@dont-email.me>
Content-Language: en-GB
Bytes: 7435

On 11/04/2025 13:32, bart wrote:
> On 11/04/2025 09:14, David Brown wrote:
>> On 11/04/2025 01:10, bart wrote:
>>> On 10/04/2025 23:18, Janis Papanagnou wrote:
>>
>>>>
>>>> *If* you're really interested in the topic, and since all the other
>>>> posters obviously gave up to continue explaining their sight to you,
>>>> why don't you accept that suggestion and read the standard document
>>>> to have clarity about the topic? [FYI; this was a rhetoric question.]
>>>
>>
>> I had certainly given up and moved on.
>>
>>> I've read the document, or the relevant section. 
>>
>> Finally!  Now you too can move on.
>>
>>> According to that, DB was wrong, and TR was half-right.
>>>
>>
>> Yes, it seems I was inaccurate about the compatibility - the names of 
>> the struct and fields need to match across translation units, not just 
>> the types of the fields.  That's why it is important that /you/ read 
>> the standard.
> 
> But no one, absolutely no one, said outright that you were wrong. Only 
> Keith eventually agreed that one of you (and Tim) was right, but didn't 
> care who, and the next day admitted that one of you might be wrong, but 
> still didn't want to commit himself as to who it might be.

Some people (certainly Kaz) gave accurate explanations without bothering 
to say explicitly who was right or wrong.  Others posted with fewer 
details - presumably because they didn't want to go to the effort of 
establishing exactly what the rules are.  After all, none of this is of 
any concern to most serious C programmers - we all know that "struct" 
(and "union") create types, "typedef" creates type aliases, if you want 
to use the same type in several places in one translation unit you 
re-use the same type, and if you want to do so across translation units 
you declare the type in a shared header.  The precise compatibility 
rules are typically only relevant if you are dealing with jumbled and 
poorly structured code.

> 
> On the other hand, I was the only one not to make a bold claim one way 
> or another (I said types were compatible enough for my test to work), 
> but Keith had no hesitation in telling me I was 100% wrong!

"Type compatibility" is a specific term in C with a specific meaning. 
It is a binary relationship - two types are compatible, or they are not 
compatible.  You can't have "compatible enough".

It is true that some compilers are laxer than others in regards to type 
compatibility.  It is possible that some compilers do not issue the 
required diagnostics when you mix incompatible types in ways that 
violate constraint requirements.  It is certainly the case that some 
compilers do not do any kind of analysis for optimisation based type 
compatibility (known as "type-based alias analysis" or "strict 
aliasing") - in which case, as long as you use casts or other 
conversions you can pretend that types with identical representations 
are compatible in non-portable code for those specific tools.

However, it is also certainly true that some compilers /do/ make use of 
the type compatibility rules to generate more optimal code, or for 
better static analysis.  It is also certainly true that some programmers 
make use of incompatible types to ensure that some kinds of mistakes in 
their code result in compile-time errors, thus reducing the risk of errors.

And it is always the case that some things may "just work" even though 
the behaviour is undefined in C or the code breaks constraints or other 
requirements.  That is never a good thing to rely on, unless you 
understand exactly why the code is problematic, and exactly why it works 
in the given situation despite the issues, and if you are happy with the 
non-portable code.

> 
> That is what is very worrying to me, and makes this a toxic environment 
> (see my last post here where I remark on the contrast with how KT treats 
> me and how he treats TR.)

My impression of KT is that he always tries to argue the case, not the 
person - thus he has had agreements and disagreements with Tim, and has 
sometimes answered your questions as well as he could while at other 
times he expresses his frustration at your determined misunderstanding 
of C and refusal to learn about it or read relevant parts of the standards.

> 
>> Tim was, as usual in these matters, entirely correct as far as I can 
>> see.  I don't see how he could be considered "half-right" here.  Tim 
>> has a communication style that some people find grating (to put it 
>> mildly), but there is no question that his knowledge of the C 
>> standards is outstanding.
> 
> I said half-right because as he put it, it sounded as though 
> compatibility depended entirely on struct tags.

He did not say that, and I as I read his post, I don't interpret it as 
implying that.  There are a number of criteria needed for two structs to 
be compatible across translation units.  Your example there failed the 
first criterium, and I suppose Tim didn't feel the need to go any 
further.  Perhaps it would have been more helpful if he had, or if he 
had at least indicated that other things were important, but the post 
was not wrong or even half-wrong.

> 
> (Which I then proceeded to put to the test with examples where there 
> were no tags, and those where the tags were the same (but defined in 
> different scopes). But these were examples where both structs were 
> visible to the compiler.
> 
> In my original example, the compiler could only see one at a time, as 
> they were in different translation units.)

Testing can only prove the existence of bugs, not their absence.