Re: question about linker

On 01/12/2024 15:50, David Brown wrote:

On 01/12/2024 15:23, Bart wrote:

Such lists might have been helpful to some people decades ago, when editors were more primitive.  If I need a list of functions in a file (maybe it's someone else's code, or old code of mine), any programmer's editor or IDE will give me it - updated correctly in real-time, and not out of sync.

>
Why isn't this a problem for exported/shared functions?
>
That is, for all sorts of functions and variables declared in headers where there is a declaration in header, and a definition in some 'home' module.
>

 What do you mean here?

You said you didn't want a list of declarations to maintain for static functions within a module.
But for non-static functions, which are shared via a header, you /need/ such a list to be maintained:
  prog.h:   int F(int);
  prog.c:   #include "prog.h"
            static int G(int a);
            int F(int a) {return 0;}
            static int G(int a) {return 0;}
Here, you object to having to maintain the declaration for G, but you still need to do so for F, and inside a separate file.
The declaration for F could also get out of sync, but you don't consider that a problem?
And if it isn't because your tools help with this, then they can help with G too.

I certainly consider it a weakness in C that you don't have clear requirements and limitations for what can be in a header or a C file, or how things can be mixed and matched.  Keeping code clear and well-ordered therefore requires discipline and standardised arrangement of code and declarations.  Different kinds of projects will have different requirements here, but for my own code I find it best to be strict that for any C file "file.c", there will be a header "file.h" which contains "extern" declarations of any exported functions or data, along with any type declarations needed to support these.  My tools will warn on any mismatches, such as non-static functions without a matching "extern" declaration.  They can't catch everything - the way C is built up, there is no distinction between external declarations that should be defined in the same module and ones that are imported from elsewhere.

Yes, this is why a module scheme (such as the kind I use) is invaluable.
In the example above, you'd define both F and G in one place. There is no header and there are no separate declarations.
If another module wishes to use F, then it imports the whole module that defines F.
Some schemes can selectively import individual functions, but to me that's pointless micro-managing.
In my scheme, it is not even necessary for individual modules to explicitly import each other: a simple list of modules is provided in one place, and they will automatically import each others' exported entities (which include functions, variables, types, enums, structs, named constants, and macros).