Re: question about linker

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

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

On 30/11/2024 01:55, Waldek Hebisch wrote:

 

Hmm, in well-written code static functions are likely to be a
majority.  Some people prefer to declare all functions and
put declarations of static functions in the same file as the
functions itself.  Conseqently, function declarations are not
rare in such code.  Do you consider it well-written?
>

>
Without doubt, most functions (and non-local data) should be static.

 I have a tool that translates C programs to my syntax. Most functions of codebases I tried are marked 'global', because the C version did not use 'static'.
 Generally those functions don't need to be exported. This is just laziness or ignorance on the part of the program, not helped by C using the wrong default.
 

I agree that the default for a language should be small scope (in this case, functions should be static to the file) rather than large scope. But it's not difficult to have a habit of adding "static" to all your functions that are not exported - even for a C generator.

However, IMHO writing (non-defining) declarations for your static functions is a bad idea unless it is actually necessary to the code because you are using them in function pointers or have particularly good reasons for the way you order your code.

 A good reason might be NOT CARING how the code is ordered.

I care how my code is organised and structured.  I care, regardless of whether or not the language cares.  I might be a little freer in the the ordering if the language does not require or promote a particular ordering - but I pick the order intentionally.
I'd be quite happy with code in Python, or any other language which does not impose a bottom-up ordering like C, to be written using a top-down approach where each function calls other functions defined below it. I'd also be happy with major algorithmic functions written one place and small utility functions in a different section, or publicly callable code first then private internal code.  There's lots of organisation of code that can make sense.
I'd not be impressed with "don't care" as an organisation.

 

I don't find redundant declarations of static functions at all useful - and I find them of significant cost in maintaining files.  It is far too easy to forget to update them when you change, delete or add new functions.  And a list of such declarations that you don't feel you can trust entirely, is worse than useless.

 Why doesn't the compiler report a declaration that doen't match the definition?
 

If the declarations are a mismatch - you have a function declared and defined with different parameter or return types - it is an error.  But it is not an error to declare static functions that are never defined as long as they are never used - so renamed or deleted functions can have their declarations left behind.  ("gcc -Wall" will warn about this, but you would not want to use a tool that is potentially helpful.)  And defining and using a static function without a forward declaration is rarely considered something to warn about, so missing declarations in the list will not be diagnosed.  (Maybe clang or clang-tidy have warnings for that - they support more warnings than gcc.)

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