Re: question about linker

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.