Deutsch   English   Français   Italiano  
<viifv8$2opi7$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Sun, 1 Dec 2024 20:12:25 +0000
Organization: A noiseless patient Spider
Lines: 76
Message-ID: <viifv8$2opi7$1@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <viaqh0$nm7q$1@dont-email.me>
 <877c8nt255.fsf@nosuchdomain.example.com> <viasv4$nm7q$2@dont-email.me>
 <vibr1l$vvjf$1@dont-email.me> <vic73f$1205f$1@dont-email.me>
 <20241129142810.00007920@yahoo.com> <vicfra$13nl4$1@dont-email.me>
 <20241129161517.000010b8@yahoo.com> <vicque$15ium$2@dont-email.me>
 <vid110$16hte$1@dont-email.me> <87mshhsrr0.fsf@nosuchdomain.example.com>
 <vidd2a$18k9j$1@dont-email.me> <8734j9sj0f.fsf@nosuchdomain.example.com>
 <vidnp3$1ovvm$2@paganini.bofh.team> <vihpjh$2hgg1$1@dont-email.me>
 <vihrh1$2hk5l$1@dont-email.me> <vii0jp$2jkd9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 01 Dec 2024 21:12:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="260abbc7cb612e705398f4619d1c380f";
	logging-data="2909767"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19CNumZ29t6JtvNv0fAploO"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:4Z2eIJuyQH4iR+zndia4rZ4IMY8=
Content-Language: en-GB
In-Reply-To: <vii0jp$2jkd9$1@dont-email.me>
Bytes: 4589

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