Re: do { quit; } else { }

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.
But it is true that some compilers have by default supported an extension that was designed to make interoperability with Fortran programs easier - and that extension allows C programmers to make mistakes if they don't understand the very simple rule of defining objects only once in a C program.  (I pushed for this extension to be disabled by default in gcc.)

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

It is an error to link these translation units in C - but some compilers accepted it.
You know how linkers work with assembly, so it is easiest to explain it in terms of a typical implementation (though the C standard does not require any of this).  When you write "int abc;" at file scope, without "static", the compiler will put the symbol in ".bss" if it is zero-initialised, and in ".data" if it is explicitly initialised.  At link time, if the linker sees the same symbol defined more than once, it complains.
The exception is that if the linker sees identically named symbols in a section called ".common", they are merged without complaint - that is the way Fortran handles linkage.  So some compilers put uninitialised data in a ".common" section rather than ".bss", allowing them to be linked.
This is, of course, a terrible idea, and a flaw in those compilers.

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

Yes.  One definition in the program as a whole, and as many declarations as you like.  Simple.

 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.
 

Correct.

   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 is not "ad hoc".

 So, what are the rules again for mixing 'extern' and 'static' declarations? Since this passes gcc:
    static int def;
   static int def;
   extern int def;
   static int def;
 but this doesn't:
    extern int def;
   static int def;
   static int def;
   static int def;

The rules are given in 6.2.2 of the standard under "Linkages of identifiers", as I mentioned earlier.  Of course people don't mix storage class specifiers like this - while the language rules make it clear what happens as far as the semantics of C are concerned, such duplications would be confusing or at best redundant.

 Are you sure they aren't ad hoc? Simply saying that the C standard enumerates the legal combinations doesn't make them not so!
 

The C standard gives clear rules here that make sense.  That does not mean they are the /only/ set of rules a language could have that makes sense, but they are not "ad hoc".  That would imply that combinations like this could have unpredictable meanings.