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: do { quit; } else { }
Date: Wed, 9 Apr 2025 16:00:57 +0200
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <vt5uip$inuo$11@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <8634enhcui.fsf@linuxsc.com>
 <vsph6b$ce6m$5@dont-email.me> <86ldsdfocs.fsf@linuxsc.com>
 <20250406161323.00005809@yahoo.com> <86ecy5fjin.fsf@linuxsc.com>
 <20250406190321.000001dc@yahoo.com> <86plhodtsw.fsf@linuxsc.com>
 <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>
 <vt5fed$ccri$1@dont-email.me> <vt5jfo$e5qu$4@dont-email.me>
 <vt5pjv$inuo$5@dont-email.me> <vt5rot$lgvv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 09 Apr 2025 16:01:03 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="39048323a720df50869558e92437b3ec";
	logging-data="614360"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+FB889sEHS1rb8XiycGV83bf0xaBDCw14="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:SmrPm+Gk4LIi8AzVkKodIezXh9k=
Content-Language: en-GB
In-Reply-To: <vt5rot$lgvv$1@dont-email.me>
Bytes: 5003

On 09/04/2025 15:13, bart wrote:
> On 09/04/2025 13:36, David Brown wrote:
>> On 09/04/2025 12:51, bart wrote:

>>> I'll have to think about this before replying to any other points.
>>
>> Marvellous - I'd appreciate you putting more thought into this, and 
>> less knee-jerk reactions and exaggerations.  Please also read the 
>> relevant parts of the standards before replying - at the very least, 
>> section 6.2.7p1 and section 6.2.2.  Once you have read these and tried 
>> to understand them, it will be a lot easier to clear up any remaining 
>> issues.
> 
> I'm not going to wade through reams of Standard minutiae, sorry.

Again, no one is suggesting that you read the entire C standard.  After 
all, that would clearly be an absurd idea for someone who spends such a 
lot of his time arguing about the C language and who even claims to have 
made a C compiler.

I have given you clear references to two small parts of the standard. 
It really is not a lot of effort.

> 
> Are T and U compatible types are not? The answer must be unequivocal 
> without needing to be a 'standards-head'.

I have told you several times, for different variations of that "T" and 
"U" mean.

Since you don't believe my explanations, and won't read the standards, 
I'm not sure how much more help I can be.

> This has been said in this 
> thread:
> 
> 
> BC: The types involved are somewhat different, but are compatible enough
>      for it to work. [In that the member types, offsets and overall size,
>      since pass-by-value is used, correspond]
> 
> DB: The two types are entirely compatible.
> 
> BC: Are they?
> 
> TR: No, they are not.
> 
> You say they're compatible, Tim Rentsch says they're not; who's right?
> 

You have moved the goalposts around so often that it is hard to keep 
track.  But Tim is correct - the names, when given, have to match as 
well as the types of the fields (but a typedef alias giving a different 
name to the same type is fine).

> 
> The original point I'd been making was that, in C, there is no dedicated 
> mechansism for sharing user-defined named entities like types, across 
> modules.

There /is/ a dedicated mechanism - described in 6.2.7p1.

There is also a common way to handle this - using shared header files - 
that is almost universally adopted in C programming.

It is not as strict as in some other languages, and is open to abuse - 
but you pretty much have to go out of your way to mix things up.  Follow 
normal C programming methods, and you will have no more risk of mistakes 
here than in languages with more formal inter-unit interfacing.


> I notice you ignored the example in my language, many posts back, which 
> makes it impossible to make such a mistake. 

Yes, I ignore your examples in your language - they have no bearing or 
relevance to anyone except you.  We all know there are other ways for a 
language to implement inter-unit sharing of information.  We all know 
that some of these can reduce the risk of certain errors.  We all know 
that you have to follow a simple rule in order to negate that risk in C 
- put shared types in shared headers.  No language negates all risks of 
errors - whatever language you use, you follow practices that balance 
the risk of errors with the convenience or flexibility that you want in 
the code.