Re: question about linker

Bart <bc@freeuk.com> writes:

On 29/11/2024 23:44, Keith Thompson wrote:

Bart <bc@freeuk.com> writes:

On 29/11/2024 20:35, Keith Thompson wrote:
(So it would have a different type from E declared on in the same
declaration:
>
    int D[3][4][5], E;
>
? In that case tell that to David Brown!)

Yes, of course D and E have different types.  I'm certain he's
aware of that.

>
Apparently the quibble is about the meaning of 'totally different'. I
would have thought that 'incompatible' would have covered it.

No, "incompatible" has a specific meaning in C which is unrelated to
what we're talking about.

But it looks like, for the sake of argument, types aren't 'totally'
different if they have even the slightest point of similarity. So an
'int' type, and a bloody great function, not even a real type, must be
considered somewhat identical if the latter happens to returns an int?

I won't try to speak for David.  I speculated about what he meant by
what was I presume was a throwaware phrase used in a specific context.
(I probably read it at the time, but I don't remember.)  I will not
discuss the meaning of "totally different types" any further.

In my language which you despise but provides a great perspective,
variables declared in the same declaration have 100% the same type. If
they are even 1% different, then that is a separate type and they need
their own declarations. They are no gradations!

You claim that I "despise" your language.

That is a lie.

I'm simply not interested in it.  If I were, I'd be glad to discuss it
in, say, comp.lang.misc.

It is a fact that a C declaration can declare multiple entities,
possibly of different types, but with restrictions on which types can be
combined.  I have not expressed an opinion on whether I think that's a
good idea.  It's a feature that I rarely take advantage of.

What "range of types" do you think D can have?

>
If DB is talking about the type of D[i][j][k], then it is also
necessary to consider the types of D, D[i] etc. That's why it's not
useful to talk about anything other than the type of the value stored
in D (and in C, before D is used in any expression).

The definition of D was :
    int D[3][4][5];
I don't know whether DB was talking about "the type of D[i][j][k]"
(which is obviously int, BTW).  I was talking about the type of D.
I've already told you what type the object D has, and the two types
the expression D can have depending on context.  I note your refusal
to answer.

Would you write "const int F();"?  Or would you omit the "const"?  How
does the fact that "const" is allowed inconvenience you?

>
It's another point of confusion. In my language I don't treat function
declarations like variable declarations. A function is not a
variable. There is no data storage associated with it.

In C, declarations can declare objects, functions, types, etc.

>
Actually types would be another category, that can also start off
looking like a variable declaration.

Yes, I mentioned types.  Your point?

to see how your language is relevant.

>
Because it's confusing in C. The perspective of a quite different
syntax /for the same class of language/ makes that extra clear to me.
>
In C all declarations are based around the syntax as used for
variables, even function definitions.

Yes, C declarations mostly follow a "declaration follows use"
pattern.  Everyone knows that.  Many, perhaps most, C programmers
don't particularly like it, but spend little time complaining about
it.  I have yet to see you make an interesting point about that fact.

In C it is unfortunate, as it makes it hard to trivially distinguish a
function declaration (or the start of a function definition) from a
variable declaration.

It's not as hard as you insist on pretending it is.  A function
declaration includes a pair of parentheses, either empty or
containing a list of parameters or parameter types.

>
Yes it is, I'm not pretending at all.
>
Perhaps you can post a trivial bit of C code which reads in C source
code and shows the first lines of all the function definitions, not
prototypes nor function pointers. It can assume that each starts at
the beginning of a line.

No.  It's straightforward for an experienced C programmer looking at
code that's not deliberately obscure.  A program that can do the same
thing reliably would have to include a C preprocessor and parser.

It's obvious that :
    int foo(int);
is intended to be a function declaration, but if there's a visible macro
definition :
    #define foo(n) foo
then it's an object declaration.  No "trivial bit of C code" will handle
that kind of thing.

No doubt you'll take that as evidence that C Is Bad rather than an
argument against writing bad code.

And I was talking about function declarations, not function definitions.
The goalposts were fine where they were.

However each may start with a user-defined type or there may be a
macros in any positions.
>
I can tell that in my syntax, function definitions start with a line
like this ([...] means optional; | separates choices):
>
  ['global'|'export'] 'func'|'proc' name ...
>
Which one do you think would be easier? (Function declarations are
generally not used.)

I don't care.

Yes, languages than C can have better declaration syntax than C does
(where "better" is clearly subjective).  Perhaps yours does.  How many
times do I have to acknowledge that before you'll stop harping on it?

Function declarations outside header files are valid, but tend to be
rare in well-written C code.

>
Function declarations are everywhere. They are usually needed for
static function otherwise you will have hundreds of function
definitions that must be written and maintained in a specific order.

I acknowledged elsewhere that I forgot about declarations of static
functions.  (Hundreds of function definitions in a single source file
seem unlikely.)

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */