Path: ...!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: Sat, 30 Nov 2024 16:57:41 +0100
Organization: A noiseless patient Spider
Lines: 133
Message-ID: <vifcll$1q9rj$1@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 30 Nov 2024 16:57:43 +0100 (CET)
Injection-Info: dont-email.me; posting-host="6c377fd0aed85814f5c9902cfb7322c7";
	logging-data="1910643"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18f7xbQQSxMwMC1HPQndFY4bbkmomVmqAA="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ZRlsOmVbQM5cW0wAf+BoDm5eXF4=
In-Reply-To: <vid110$16hte$1@dont-email.me>
Content-Language: en-GB
Bytes: 6344

On 29/11/2024 19:26, Bart wrote:
> On 29/11/2024 16:42, David Brown wrote:
>> On 29/11/2024 15:15, Michael S wrote:
>>> On Fri, 29 Nov 2024 13:33:30 +0000
>>> Bart <bc@freeuk.com> wrote:
>>>
>>
>>>> * It allows a list of variable names in the same declaration to each
>>>>     have their own modifiers, so each can be a totally different type
>>>>
>>
>> They can't have "totally different" types - they can have added 
>> indirection or array indicators, following C's philosophy of 
>> describing the type by how the variable is used:
>>
>>      int x, *y, z[10];
>>
>> Thus "x", "*y" and "z[i]" are all of type "int".
> 
> C's syntax allows a 14-parameter function F to be declared in the same 
> statement as a simple int 'i'.

And the laws of physics allow me to drop a 20 kg dumbbell on my toe. 
That does not mean that anyone thinks it is a good idea.


> 
> I'd say that F and i are different types! (Actually I wouldn't even 
> consider F to be type, but a function.)

Functions have types in most typed languages, including C.

And yes, F and i are different types - but they are related types.  Use 
the declared identifier in an expression of a form matching what you 
wrote in the declaration, and the expression will have type "int". 
That's how C's declarations work.


> 
> That F(1, 2, 3.0, "5", "six", seven, ...) might yield the same type as 
> 'i' is irrelevant here.

No, it is exactly the point - it is how C is defined.

> 
> Usually, given these declarations:
> 
>    int A[100]
>    int *B;
>    int (*C)();
> 
> people would consider the types of A, B and C to be array, pointer and 
> function pointer respectively. Otherwise, which of the 4 or 5 possible 
> types would you say that D has here:

They are different - but related - types.

> 
>    int D[3][4][5];
> 
> It depends on how it is used in an expression, which can be any of &D, 
> D, D[i], D[i][j], D[i][j][k], none of which include 'Array' type!
> 
> Here's another puzzler:
> 
>    const int F();
> 
> why is 'const' allowed here? There is no storage involved. It's not as 
> though you could write 'F = 0' is there was no 'const'.

"const" is allowed here because it is part of the type returned by F().

Really, most of this is pretty straightforward.  No one is asking you to 
/like/ the rules of C's declarations (I personally dislike that a single 
declaration can be used for different types, even if they are related). 
But /please/ stop pretending it's difficult to understand.

> 
>> C allows this, but I personally would be happier if it did not.  As 
>> Michael says below, most serious programmers don't write such code.
> 
> It doesn't matter. If you're implementing the language, you need to 
> allow it.

I am not implementing the language.  No one else here is implementing 
it.  You have, apparently, implemented at least some of the language 
while being completely incapable of understanding it.  I am surprised 
that is possible, but it is what you seem to be claiming.


> 
> If trying to figure out why some people have trouble understanding, it's 
> something to consider.
> 

I have met a good many C programmers over the years, and some of them 
have had misunderstandings.  I have never heard of anyone who comes 
close to your level, however.

For most people new to C, it's enough to tell them that "int* a, b;" 
declares "a" as a "pointer to int" and "b" as an "int".  You tell them 
it is a bad idea to write such code, even re-arranged as "int *a, b;", 
because it is easy to get wrong - they should split the line into two 
declarations (preferably with initialisations).  The C newbie will thank 
you for the lesson, and move on to write C code without writing such 
mixed declarations.

/That/ is how you solve problems with syntax that can be abused to write 
unclear code.

> It's also something to keep in mind if trying to understand somebody 
> else's code: are they making use of that feature or not?
> 
> So this is a wider view that just dismissing design misfeatures just 
> because you personally won't use them.
> 

So what is your preferred solution?  Whine endlessly on newsgroups for 
decades on end about the same things you dislike, to people who have 
absolutely no influence on the thing that bothers you?  How productive 
has that been for you?

The sane response to a "design misfeature" is to avoid using it 
yourself, and encourage others to stop using it when you see them doing so.

> With the kind of C I would write, you could discard everything after 
> C99, and even half of C99, because the subset I personally use is very 
> conservative.
> 

You say that as though you think it is a good thing - it is not.