Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Wed, 9 Apr 2025 16:37:13 +0100
Organization: A noiseless patient Spider
Lines: 131
Message-ID: <vt647a$u6co$1@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>
 <vt5uip$inuo$11@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 17:37:14 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="86cd0c292c528f4b59336ead25869004";
	logging-data="989592"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX185arYPMRX5NXuQjBlW+nKG"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:X+1RjgkhVQJ8ry07Thn+DRSMbLY=
In-Reply-To: <vt5uip$inuo$11@dont-email.me>
Content-Language: en-GB
Bytes: 6868

On 09/04/2025 15:00, David Brown wrote:
> 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

Not really me.

> 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).

So who's right, you or Tim? Since you are saying contrary things.


>>
>> 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.

According to that, then the 'Point' and 'vector' types in my original 
two-file example are not compatible, since they have different struct 
tags, plus they have different member names. But above you say they are 
'entirely compatible'.

Maybe it's /you/ who needs brush up on the Standard! I merely said they 
are compatible enough to my program to work, since at the machine level, 
this is merely two consecutive f32 types.

BTW1 that paragraph doesn't say anything what 'pack()' setting is in 
force; that /has/ to be the same if otherwise different amounts of 
padding exist.

BTW2 that doesn't really say anything about how to share named 
non-linkage entities across translation units.

>> 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.

You're welcome to post the same example in a more mainstream language. 
However most still seem to based around independent compilation. Many 
still require two parts to each shared resource: a definition, and a 
separate interface, with some mechanism needed to keep them in sync.

My scheme only needs a definition for resources forming part of the same 
program. It also works for ALL named entities, not just those with 
'linkage'.

>  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.

If there was a 1:1 correspondence between a .c file and its .h, that 
would be great, but that rarely happens. In the LIBJPEG project for 
example, there are 76 .c files, and 12 .h files (but at least they are 
in the same folder).

There are still risks: suppose a project uses include files in multiple 
locations made known to the compiler. It will follow an 
implementation-defined algorithm to search multiple paths for an include 
file. But if one accidentally gets deleted or renamed, if may pick up up 
an identically named file elsewhere. They may be similar enough to allow 
compilation to proceed, but now it is buggy.


>  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.


The point is that C's scheme is 'ad hoc' with myriad (רבבה?) points of 
failure. You like to deny that. (Apparently if a compiler follows the 
same consistent set of rules, then it cannot be 'ad hoc'. But you can 
say this about any computer program; they are only following orders!)