Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Fri, 29 Nov 2024 17:28:22 -0800
Organization: None to speak of
Lines: 150
Message-ID: <87ttbpqzm1.fsf@nosuchdomain.example.com>
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>
	<87mshhsrr0.fsf@nosuchdomain.example.com>
	<vidd2a$18k9j$1@dont-email.me>
	<8734j9sj0f.fsf@nosuchdomain.example.com>
	<vidnuj$1aned$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 30 Nov 2024 02:28:23 +0100 (CET)
Injection-Info: dont-email.me; posting-host="d28f02e76a6c2d00a69abdf93e7df1d2";
	logging-data="1354134"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/h2lA2J0cgU3fwPza0coEe"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:n9J0iH3LISmyDn00iP45PMtQs/0=
	sha1:BtxDxlpJblpgVk2WN0UwD99tTXw=
Bytes: 7886

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 */