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: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Tue, 8 Apr 2025 12:35:34 +0100
Organization: A noiseless patient Spider
Lines: 196
Message-ID: <vt31m5$2513i$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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 08 Apr 2025 13:35:34 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2f44e72492e5a6a19c1f48ece1af5bd0";
	logging-data="2262130"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/UbICo44WX7DxSRfUG+z8y"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:/fIkkYbs9upAHtBMhA6erOtHmH4=
Content-Language: en-GB
In-Reply-To: <vt2lp6$1qtjd$1@dont-email.me>
Bytes: 7989

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?

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



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

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.

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

This is what I mean by 'ad hoc'.


This is how it looks when there is language support; first module A:

--------------------------
   module b                  # (imports b)

   proc main=
       point p := (3, 4)

       println dist(p)
   end

--------------------------

Module B:
--------------------------
   global record point = (real32 x, y)

   global fun dist(point p)real32 = sqrt(sqr(p.x) + sqr(p.y))
--------------------------

(Example from one of mine, which uses whole-program compilation) Here, 
unlike C, you need to decide which module owns and exports the type. 
Then, there is only that one version which is shared.

However similar problems to C can occur when sharing across /programs/, 
which could be written in different languages (eg. libraries).

I don't know if or how the C standard addresses that, since it can only 
talk about the C language. For that matter, a single program with 
independently compiled modules might have only some of those in C.

So there is even more scope for ad hoc-ness.

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

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

How compilers deal with it have changed. But right now, if I put this in 
a header shared by A and B modules:

   int abc;

I get 'multiple definition' of abc (from some compilers; others have no 
problem).

If I stick 'extern' in front, I get 'undefined reference' of abc. To 
make it work, 'extern int abc' is shared, and one module must see 'int abc'.

However if I need to initialise the variable:

    extern int table[];          // shared
    int table[] = (10, 20, 30)

then other modules can't pick up length of the array.


  and does not need additional
> specialised object files or "interface" files.  It is possible to write 
> C code in an "ad hoc" manner (such as declaring an "extern" identifier 
> within a C file rather than a header file), but the language definition 
========== REMAINDER OF ARTICLE TRUNCATED ==========