Re: question about linker

Bart <bc@freeuk.com> writes:

On 04/12/2024 19:47, Janis Papanagnou wrote:

On 04.12.2024 13:08, David Brown wrote:

Sure.  And it is certainly /possible/ to know all the small details of C
without ever reading the standards.  But it's quite unlikely.

The question is (IMO) not so much to know "all" and even "all small"
details. Even in a language like "C" (that I'd consider to be fairly
incoherent if compared to other languages' design) you can get all
"important" language properties (including details) from textbooks.
If cases where that is different, the standards documents - which
have their very own special way of being written - would be even
less comprehensibly as they (inherently) already are. - That said
from a programmer's POV (not from the language implementors').
I look into language standards only if I want to confirm/falsify
an implementation; in this case I'm taking the role of a language
implementor (not a programmer). Personally I do that anyway only
rarely, for specific languages only, and just out of academical
interest.
 

[...]
Bart is an expert at thinking up things in C that confuse him.

Well, that's an own topic. - Where I was really astonished was the
statement of being confused about the braces/semicolons, which is
so fundamental (and primitive) but technically just a detail that
I'd thought it should be clear

>
OK, if it's so simple, explain it to me.

I'll pretend that was a sincere 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?

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?
(I'll note that languages that use "begin"/"end" rather than "{"/"}"
often require a semicolon after the "end".)

And you can add a semicolon after a compound statement if you like
(it's a null statement), as long as the compound statement isn't
a function body.

Of course you know all this.

The C language is one of the most quirky ones around full of
apparently ridiculous things. Why shouldn't you be able to write this
for example:
>
   {
   ....
   L:
   }
>
This stupid rule means that EVERY label in my generated code needs to
be written as L:; instead of just L:
>
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.

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.)

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