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: Tue, 8 Apr 2025 16:50:56 +0200
Organization: A noiseless patient Spider
Lines: 267
Message-ID: <vt3d4g$2djqe$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 08 Apr 2025 16:50:58 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="36723575c292a64f7875af78bfff292a";
	logging-data="2543438"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/jSTawgRba1M6vvchUcbai8rh6BfKXz8U="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:SK/zYwWzsbfTI9PTAp7APcJkGsk=
Content-Language: en-GB
In-Reply-To: <vt31m5$2513i$1@dont-email.me>
Bytes: 11518

On 08/04/2025 13:35, bart wrote:
> On 08/04/2025 09:12, David Brown wrote:
>> On 07/04/2025 20:31, bart wrote:
>>> On 07/04/2025 19:02, Michael S wrote:
>>>> On Mon, 07 Apr 2025 05:45:19 -0700
>>
>>>> Of course, proposals for similar feature in other procedural/imperative
>>>> language would not be totally different. Pascal is more similar to C
>>>> than many other procedural languages, so solution for Pascal would
>>>> likely be more similar to C than for example, stackless co-routines
>>>> that already exist in such languages like C# (that started current wave
>>>> of popularity of the feature) or Python.
>>>> However Pascal and C have enough not in common for significant
>>>> difference in proposed syntax and implementation. Specifically, in
>>>> Pascal:
>>>> - heap management is built-n in the language
>>>> - non-local goto is built-n in the language
>>>
>>> That's news to me. But then I only used an educational version.
>>>
>>>> - nested procedures
>>>> - everything related to separated compilation of the translation units
>>>> is handwaved in the docs rather than strictly specified.
>>>
>>> I don't think it's that strictly specified in C. Isn't it vaguely 
>>> left to the implementation?
>>>
>>
>> No.
> 
> C simply has the requirement for separate compilation of modules. Where 
> does it specify how the implementation does that?

The details of how a compiler (and linker) run are not part of a 
language specification.  But how separately compiled units interact is 
in the standard.

> 
>>> Much of how different units share macros, types, structs and enums 
>>> isn't part of the language at all AFAICS: it's just a by-product of 
>>> different modules happening to include the same header files.
>>>
>>
>> Linkage is explained in 6.2.2 - only identifiers with external linkage 
>> are shared amongst translation units.  Macros, types, enums are all 
>> have no linkage and are therefore never shared.
> 
>  From the programmer point of view, they are shared. But the language 
> provides no specific mechanism for that.
> 

No, of course not.  A language specification says what the language 
/means/, not how tools make that happen.  That is a good thing - if the 
C standards had specified that translation units get compiled to object 
files and then a linker is used, you couldn't have link-time 
optimisation or whole-program compilation.

> 
> 
>> The only way to make new non-standard types in C is with "struct", 
>> "union" or "enum".  Section 6.2.7 of the standard sets out simply and 
>> clearly what is required for two types in different translation units 
>> to be compatible.  (It doesn't make sense to say they are the "same 
>> type" in C lingo, since types have no linkage, but compatibility is 
>> the important point.)
>>
>> Sharing a definition in a header file is normally the easiest way to 
>> ensure that the types used in different translation files are 
>> compatible, but it is not required.
>>
>>> But it could also be done by repeating declarations in each module; 
>>> it's rather ad hoc.
>>
>> It is not remotely "ad hoc" - as far as the language is concerned, 
>> including a header file /is/ repeating the declaration in the 
>> different translation units.
> 
> The programmer can achieve the objective in multiple ways; that's what's 
> ad hoc.

As I said - the C standards and the language are not ad hoc.  But it is 
possible to write ad hoc code.

> The implementation itself works by crossing its fingers and 
> hoping that the multiple declarations of the common entity X that are 
> seen by the different translation unit are fully compatible.
> 

Nope.  You are just making stuff up in your never-ending quest to 
misunderstand C and pretend everything about it is terrible.

But it is certainly true that the inter-unit interaction in C is less 
rigid and controlled than in some other languages.  That keeps the 
language and its definition simpler, allows simpler implementations, and 
gives more programmer flexibility (especially if they are happy with 
non-portable code).  The flip side is that it also allows more abuse or 
accidental mistakes, and requires more advanced tools to diagnose 
problems (such as using link-time optimising compilers or whole-program 
analysis tools).

> But this need not be the case. For example this is module A:
> 
> --------------------------
>    #include <stdio.h>
> 
>    typedef struct point {float a; float b;} Point;
> 
>    float dist(Point);
> 
>    int main(void) {
>        Point p = {3, 4};
>        printf("%f\n", dist(p));
>    }
> --------------------------
> 
> And this is module B that defines 'dist':
> 
> 
> --------------------------
>    #include <math.h>
> 
>    typedef float length;
>    typedef struct _tag {length x, y;} vector;
> 
>    length dist(vector p) {return sqrt(p.x*p.x + p.y*p.y);}
> --------------------------
> 
> The types involved are somewhat different, but are compatible enough for 
> it to work.

The two types are entirely compatible.  "typedef" does not introduce a 
new type, and struct types in different modules are compatible if they 
are build from the same compatible field types in the same order.

> 
> However, they could also be different enough (in a more elaborate 
> example) for things to superficially work.

Not in C.

> 
> This is what I mean by 'ad hoc'.

If that's what you meant by "ad hoc", you were wrong about C being "ad hoc".

> 
>> The way C handles this kind of thing is arguably weaker than in 
>> languages that have proper modules (like Ada, or Modula 2), and much 
>> more open to mistakes.  On the other hand, it is very flexible and 
>> simple to understand,
> 
> 
> The preprocessor mechanisms available to work with source code are 
> fairly easy to grasp (but may be complex in practice with multiple 
> nested headers spread over a file system).

That's like complaining that integer addition is complex because someone 
might want to add 26 digit numbers.  Stop being silly.

> 
> But I had, and do still have, difficulty with how exactly you import and 
> export entities, even ones with linkage.

That sounds very much like a "Bart" problem.  If you /genuinely/ want to 
know, and you can't figure it out with a quick google search, reading 
the page in the standards, or looking at an introduction to C book, then 
please ask.  If you are just trying to claim opportunities to say it's 
all so difficult and confusing, then don't bother.

> 
> How compilers deal with it have changed. 

As a general rule, they have not.
========== REMAINDER OF ARTICLE TRUNCATED ==========