Re: Endless complaints [was Re: do { quit; } else { }]

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.