Re: question about linker

On 04/12/2024 16:38, Tim Rentsch wrote:

Ben Bacarisse <ben@bsb.me.uk> writes:
 

Bart <bc@freeuk.com> writes:
>

On 03/12/2024 11:15, Ben Bacarisse wrote:
>

Bart <bc@freeuk.com> writes:
...
>

If I write this
>
    int *A, B[10], C(int);
>
My compiler tells me that:
>
    A is a local variable [...]
    B is a local variable [...]
    C is a function with return type of 'i32', taking one
      unnamed parameter of type 'i32'.
>
(Interestingly, it places C into module scope, so the same
declaration can also create names in different scopes!)

 That means your compiler is not compiling standard C.  In standard C
all entities declared locally have block scope, not file scope.

OK, it can be added to the list of things that make C harder to compile.
Elsewhere the discussion ventured into module schemes and I complained about those that needed or allowed external functions to be individually imported, instead of just importing everything a module exports.
C needs individual declarations to import a bunch of functions from elsewhere. But it goes further: each function in this module can define its own private subset of imported functions!
Actually it goes further still: each nested block scope can also define its own subset. So there can be several such sets within any function, and each function can have its own collection of sets.
To me, that is frankly crazy.
So actually I'm glad I don't implement that. And maybe that pointless freedom can be dropped from future versions.

That doesn't invalidate your reaction to Bart's statement, because
he is being sloppy with language,

But creating a tighter, more rigorous subset of C too, even if not intentionally.
It comes down to whether you are implementing a tool that will mindlessly translate all existing C code (which I now know could take a lifetime), or one that will let you write or generate new, useful programs in a large subset of the language.