Path: ...!news.misty.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Tue, 3 Dec 2024 16:24:18 +0100
Organization: A noiseless patient Spider
Lines: 89
Message-ID: <vin7r2$49d1$2@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me> <vi6sb1$148h7$1@paganini.bofh.team>
 <vi6uaj$3ve13$2@dont-email.me> <87plmfu2ub.fsf@nosuchdomain.example.com>
 <vi9jk4$gse4$1@dont-email.me> <vi9kng$gn4c$1@dont-email.me>
 <87frnbt9jn.fsf@nosuchdomain.example.com> <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> <vifcll$1q9rj$1@dont-email.me>
 <vifiib$1s07p$1@dont-email.me> <87ldwx10gv.fsf@bsb.me.uk>
 <vimtt4$27vv$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 03 Dec 2024 16:24:18 +0100 (CET)
Injection-Info: dont-email.me; posting-host="45d82f8154cbe9004813104a252e0aff";
	logging-data="140705"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/N5wShRWJYw83vI207Ej6TE+z7t4GAcrE="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:MX7aNEy2q5AiDMUmjGmnIVBgVOw=
In-Reply-To: <vimtt4$27vv$1@dont-email.me>
Content-Language: en-GB
Bytes: 5436

On 03/12/2024 13:34, Bart wrote:
> 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 with type 'ref i32' (expressed in other syntax)
>>>    B is a local variable with type '[10]i32'
>>>    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!)
>>
>> A small correction: that declaration gives all three names the same
>> scope[1].
> 
> This is what I observed my compiler doing, because it displays the 
> symbol table. It puts C into module-scope, so I can access it also from 
> another function without another declaration (so non-conforming, but I'm 
> long past caring).
> 
> I can't see gcc's symbol table, but I can't access C from another 
> function without it having its own declaration, or there being a 
> module-scope one.

Declarations are scoped in C.  Of course you can't make a declaration 
like this inside one block and then access it from inside another block 
(that is not a subblock).  You don't need to see gcc's symbol table to 
understand this - you just need to know the basics of structured 
programming.

> 
> With gcc, such a declaration inside a function suffices to be able 
> access a function 'C' defined later in the file.

"int C(int);" declares that there exists an external linkage function 
"C" with prototype "int C(int)".  If that identifier is used, then there 
must be a single function of that name and type defined somewhere in the 
program (in the same file or a different file).  The block-scope 
declaration is only visible within that one block, of course.

> 
>>  You are confusing scope with linkage.
> 
> It's possible. So a function declaration inside a function gives the 
> name external linkage (?). 

The declaration "int C(int)" is an external linkage declaration, because 
that is always the case for function declarations that are not 
explicitly declared "static".  (And you can't have a static function 
declaration at block scope.)

> Which in this context means the function will 
> be outside this one, but elsewhere in the module, rather than being 
> imported from elsewhere module.

Not at all.  It could be elsewhere in the unit, or in a different unit. 
There is no distinction.

> 
> If I say I find these quirks of C confusing, people will have another go 
> at me. So let's say it makes perfect sense for 'extern' to mean two 
> different things!
> 

Of course people will have another go at you for making wild and untrue 
assertions about things that should be pretty obvious to anyone who has 
thought about and read about scopes, identifiers and declarations - and 
which pretty much no one would ever write in real code.

You are under no obligation to make your compiler conforming, but you 
don't get to claim you have made a compiler with different rules from C 
and that means C is confusing or ambiguous!  It simply means that /you/ 
were wrong, /you/ got confused, /you/ didn't make any effort to look at 
the standards and the definition of the language.

Of course lots of C programmers have never read the standards.  But they 
generally know that they don't know these details, and don't try to 
pretend that the language details that they don't know are confusing. 
They simply get on with the job of writing clear C code as best they can.