Re: do { quit; } else { }

On 08/04/2025 15:50, David Brown wrote:

On 08/04/2025 13:35, bart wrote:

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.

Are they? So why does gcc report an error here (the two types are from my example):
   typedef struct point {float a; float b;} Point;
   typedef float length;
   typedef struct _tag {length x, y;} vector;
   Point p;
   vector v;
   p=v;
c.c:14:5: error: incompatible types when assigning to type 'Point' {aka 'struct point'} from type
ector' {aka 'struct _tag'}
    14 |   p=v;
       |     ^

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

Really? I could have added a dozen extra fields to one (or a pile of incompatible fields to both), and it can still work (especially if I pass the struct by reference).

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.

You're missing the point: the concept may be simple, but as typically used in C, it is can be much more complex than necessary. Doing:
   #include "lib.h"
is not enough; there may be a dozen different header locations (from nested includes) that need to be made known to the compiler, so you need to figure them out first!
A program may comprise 100 .c files, but use 37 different headers in mixed, possible nested combinations across those 100 modules. You can't in general tie one .c file to a specific .h file; /that/ would be simpler.
So the usual thing applies in C: the language lays down some vague rules, beyond that it's a free-for-all.
You choose to call that 'being flexible'; I might call it something else.

 

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

You really think that I wouldn't know how to do this if the language provided genuinely simple and well-thought-out and consistent rules?
Here are some rules from another of my languages; this time it's an assembler:
   L1:                     # local label
   L2::                    # exported label
       call puts*          # imported symbol
       call fred           # name defined in this file (which may be
                           # local or exported depending on : or ::)
There are no explicit sets of declarations (eg. 'extern puts' as in other products); no forward declarations are needed.
Simple, yes?

  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.

Ah yes, the Microsoft approach: provide huge amounts of resources, manuals, training courses etc, rather than making something actually simple!

>
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

Which means a pile of badly written programs.

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 the workaround is...?
(Maybe you can appreciate one of many reasons why I normally generate C code for a project as one source file.)

The C standard gives clear rules here that make sense.

What's the rational for allowing both static and extern versions of the same entity in the same file? And if that is allowed, why does the order matter?
(In my compiler I gave up trying to make sense of it, and just ended up allow any combination unless it was clearly wrong.)
   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.

I don't mean 'ad hoc' to be 'indeterminate'. More like, 'mess', or 'free-for-all'.