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: Wed, 04 Dec 2024 16:19:59 -0800
Organization: None to speak of
Lines: 152
Message-ID: <87a5db0ymo.fsf@nosuchdomain.example.com>
References: <vi54e9$3ie0o$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>
	<vin7r2$49d1$2@dont-email.me> <vinalt$5qoh$1@dont-email.me>
	<vipgns$rjqn$1@dont-email.me> <viqbl8$12mum$1@dont-email.me>
	<viqfuh$131h8$2@dont-email.me>
	<87ttbj12ec.fsf@nosuchdomain.example.com>
	<viqq95$164ug$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Thu, 05 Dec 2024 01:20:00 +0100 (CET)
Injection-Info: dont-email.me; posting-host="7392a70ceafa2370b36a4bd73810300d";
	logging-data="1211084"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+W2UQccYmA32httKJjzPWm"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:aaeHc0PU9ahHHgPFV7kMxk/XSXo=
	sha1:tiKeUyayRHfpL5ND41+qyPNYOy4=
Bytes: 7736

Bart <bc@freeuk.com> writes:
> On 04/12/2024 22:58, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> OK, if it's so simple, explain it to me.
>> I'll pretend that was a sincere question.
>
> Let's put it this way: if somebody asked me what the rule was, I
> wouldn't be able to tell them.

Probably because there's no single rule.  As I wrote, "{" and "}"
are used in different contexts with different meanings.  (So are
"(", ")", ";", and "static".)  I have no particular expectation
that there should be a single rule covering all the cases, just
because they happen to use the same symbol.

A reasonable person would have ackowledged that I've at least tried
to answer your question.

>> You seem to be under the impression that a closing brace should
>> either always or never be followed by a semicolon.  I don't know
>> where you got that idea.
>> Braces ("{", "}") are used in different contexts with different
>> meanings.  They're generally used for some kind of grouping (of
>> statements, declarations, initializers), but the distinct uses are
>> distinct, and there's no particular reason for them to follow the
>> same rules.
>> 
>>> Apparently the first line here needs a semicolon after }, the second
>>> doesn't:
>>>
>>>    int X[1] = {0};
>>>    void Y() {}
>> Yes.  The first is a declaration, and a declaration requires a
>> semicolon.  I suppose the language could have a special-case rule
>> that if a declaration happens to end with a "}", the semicolon is
>> not required, but that would be silly.
>> The second is a function definition (and can only appear at file
>> scope).  Function definitions do not require or allow a semicolon
>> after the closing "}".  Why should they?
>
> Consistency? I posted a bit of Algol68 the other day; each function
> definition needed a semicolon, to separate it from the next.

C is not Algol68.  In C, the syntax of a function definition is such
that they can be appended without ambiguity.  Requiring a semicolon
after each definition would not help anything.  And it would break
most existing C code.

>>> Similarly here:
>>>
>>>    if (x) y;
>>>    if (x) {}
>>>
>>> Why?
>>>
>>> "Because that's what the grammar says" isn't a valid answer.
>> Because that's what the grammar says.
>> Not all statements require a closing semicolon.  In particular,
>> compound statements do not, likely because the closing
>> "}" unambiguously marks the end of the statement.  Sure, the
>> language could have been specified to require a semicolon, but why?
>
> Consistency again? But then you'd get this: if () {}; else {};. It
> would be incompatible with how it works now.

So there's a good reason for the current definition.

> So overall it's just messy. It works for BEGIN/END when semicolon is a
> separator, rather than a terminator. So you write END ELSE not END;
> ELSE.
>
> But because C uses ";" as a terminator, it's made a rod for its own back.

The solution (for programmers) is simple.  Don't add a ";" after the
closing "}" of a compound statement.  You *can* add the ";" in some
cases, but there's no point in doing so.

>> (I'll note that languages that use "begin"/"end" rather than "{"/"}"
>> often require a semicolon after the "end".)
>
> That's my A68 example.
>
>> And you can add a semicolon after a compound statement if you like
>> (it's a null statement),
>
> But not here I guess:  if () {}; else ...

You're right, I missed that case.

>> Of course you know all this.
>
> I'm aware of how messy and conistent it is. I've said that languages
> that use ";" as a separator probably fair better, but are still not
> ideal because the last statement of a block is now an annoying special
> case.

No, I'm saying that you already know what the rules are.  You have
access to multiple C (draft) standards and books.  You've written a C
compiler yourself.  I honestly don't believe you're as confused as you
pretend to be.

[...]

> Meanwhile, if I compile this:
>
>   void F(){}; void G(){};
>
> My compilers report a syntax error. But gcc passes it by default. So I
> take what the grammar says more seriously than gcc!
>
> IS ";" between function definitions legal or not? If not, then fail
> the program.

Bart, you already know that gcc by default is relatively lax, and is in
fact not a conforming C compiler, since it fails to produce many
required diagnostics.  You've been told again and again how to invoke
gcc so that it will at least attempt to be a conforming C compiler, for
any of several editions of the C standard.  But you still pretend that
gcc's default behavior says something about the C language.

>>> Please don't say the label is only defined to be a prefix to another
>>> statement. I asking why it was done like that.
>> The label is only defined to be a prefix to another statement.
>> It was simple to define it that way, and not particularly
>> inconvenient to add a semicolon if you happen to want a label at
>> the end of a block.  I'd be surprised if this rule has ever actually
>> caused you any inconvenience.
>
> I said that my generated code has to use ":;" after each label; it
> looks weird.

I stand corrected.  The rule has caused you some trivial inconvenience.
(Apparently you care about generated code looking weird; I'd expect
weirdness to be inevitable.)

>> But you'll be delighted to know that C23 changed the grammar for a
>> compound statement, so a label can appear before any of a statement,
>> a declaration, or the closing "}".  So now you have exactly what you
>> want.  (Just kidding; you'll still find a way to be angry about it.)
>
> No, that's amazing. Presumably, some people must complained about it
> (maybe it actually caused some inconvenience!), and it eventually got
> fixed.
>
> Of course, if it was just me, then it would be pointless ranting. 'How
> hard is to add the semicolon?'
>
> Well, 'How hard is it to delete the semicolon' from my above example?

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