Re: do { quit; } else { }

On 08/04/2025 18:28, bart wrote:

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?

Yes.

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;
       |     ^
 

That is a different situation.  In the first case, the types were defined in different translation units - and are compatible.  In the second case, they are within the same translation unit, and are not compatible.
In C, if you declare two structs in the same translation unit with the same field types and the same field names, they are still different types.  That is important for making new types - it is how you get strong typing in C (albeit with less user convenience than in some other languages).  It means that you can't mix up two types just because of coincidences in the fields.
This means that when you have a struct declaration in two translation units (locally in the C file, or via a header file - there is no distinction), they form two different types as they are separate declarations.  If C did not specify that these were compatible, it would be impossible (without UB) to use struct or union types across translation units.
This is a situation where C's system is weaker than a solid module solution, but it works extremely well in practice - especially if developers follow the simple and common habit of putting shared type declarations in shared header files.

 

"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 fact that something happens to work does not mean that it is defined behaviour in C.
Of course it can be appropriate to write non-portable code that "just works".  Making a pointer to one struct type, then using it as though it is a pointer to a different struct type like this is very likely to "just work" as long as you stay within the common part of the struct types.  But there also may be circumstances in which it does /not/ "just work", or it might not work with other compilers or other options.

 

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.

The C language is defined as explained in the standards.  If someone writes C code that you think is more complex than necessary, talk to the person writing that code.

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!

That is a question of build environment and build instructions.  It applies to every programming language.  Any time one file refers to another, you need some way to be sure you get exactly the file you intended.

 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.
 

This applies to all languages.  For example, in Python you do not have separate "interface" and "implementation" files - everything is in one ".py" file.  If I have a Python module that says "import my_py_lib", how does Python know where to find "my_py_lib.py" ?  How does it know which copy of "my_py_lib.py" to use from the dozen that I have on my computer?   The answer is it uses some default rules for the language, some default rules for the implementation, some configuration settings, some flags, some run-time information (equivalent to compile-time information in compiled languages).  The exact details are different, but the principle is the same for C and for any other language that can handle more than one file.

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?

Apparently, that is the case.  It does surprise me a little that you find this difficult - especially since you claim to have written a C compiler but don't seem to have read any of the language standards.

 

  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!

It is /one/ **beeping** page in the standard!  It is in /one/ section - section 6.2.2 - titled "Linkages of identifiers".  Seven paragraphs, none of which are more than 5 lines long.

 

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

That is why I said it was a bad idea for gcc to have "-fcommon" as the default.  It is a real shame that it took so long to change it.
However, while that default meant that some people wrote C code with a misunderstanding of linkages and the difference between declarations and definitions, most C programmers don't make that mistake.  When gcc eventually changed the default, it did not lead to wide-spread breakage of code.

 

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

Learn how arrays work in C, and how you can pass around the length of an array between different functions or translation units.

 (Maybe you can appreciate one of many reasons why I normally generate C code for a project as one source file.)

I can appreciate that you are the sort of person who, when finding a hole in their sock, would rather chop off their foot than go to the effort of buying a new pair.
No one claims that C is the ideal language for all programming tasks or all programmers - if you would rather use a different language, that's fine.  It's the petty griping and whining about things that are simple and clear that is so pathetic.  You /know/ that C does not pass on the array size in the case you give above.  You /know/ you have not shared that information with the second unit.  You /know/ that no language lets one unit or module know information from a different unit or module if that information is not shared.  And you know perfectly well how you can pass around the information in C when you need to.

 

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?

I believe the meaning of "extern" in combination with other storage-class specifiers was picked to work with existing old code from before "extern" was added to the language.
(You might not think this is a good reason, or prefer the rules to be different - that's fine.  I would certainly prefer stricter rules, and use compiler warnings to enforce those preferences in order to reduce the risk of errors in my code.)

 (In my compiler I gave up trying to make sense of it, and just ended up allow any combination unless it was clearly wrong.)

Again, it is /one/ page in the standard.  It is not rocket science.  The idea that a person could be smart enough to make their own compiler and not smart enough to understand the rules around linkage in C is utterly laughable.  You have are intentionally misunderstanding this so that you can claim C is confusing or badly designed.  This is deceitful behaviour.
No one is asking you to /like/ the rules of C.  No one is asking you to think they are ideal.  Certainly no C programmer I know likes all of C's design, though they vary on what they like and dislike.  But you are clearly wrong about these things being hard to understand.

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

You are still wrong.