Re: question about linker

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