Re: question about linker

On 07/12/2024 14:36, Janis Papanagnou wrote:

On 07.12.2024 14:04, Bart wrote:

 Just fine, I'd say.
 

But it relies on some subtlety.

 You seem to see ghosts. There's no subtlety; all is clearly defined,
and it's a sensible feature, and consistently implemented.
 

'while (cond)' both starts a statement, and can
end a statement:
>
    do while(cond) do ; while (cond);

 What is this (IMO syntactical wrong "C" code) supposed to do or to
explain?

See my follow-up.

Your (wrong) second 'do' was indeed confusing! - Why did you provide
a wrong sample to confirm your wrong ideas? - Or is it just your well
known habit to try to confuse other folks as well my making up stupid
things?

You're being aggressive. It was a mistake, that's all. My original example was meant to show how it gets confusing, but when I transcribed it into an actual program, it seemed to work because I'd left out that 'do'.
It says something however when I actually believed that that code was valid, because the compiler appeared to say so.

Most here (and me too) already acknowledged that "C" is not obvious
to you.

Why is it not possible for to acknowledge that some language design patterns may not be as obvious as others?
According to you, even if some construct can be determined to be unambiguous in some convoluted grammar, then it must also be 100% obvious to any human reader?
Is it just to avoid admitting that I might have a point?

You don't think there is an element of ambiguity here?

 There isn't any.

So you're a parser and you see this:
     do ... while
How do you know whether that 'while' starts a new nested loop or terminates this one?
What does it depend on; what property of blocks in the language is needed to make it work? What property of statement separators or terminators is needed.
In C, it apparently relies on blocks (that is, the statements in a loop body) being only a single statement, as it is in C. So the pattern is this:
   do {...} while ...
   do stmt; while ...
   do ; while ...
But not however these:
   do {...}; while ...
   do while ...            # this can't be the terminating while.
So it can't work in a syntax which allows N statements in a block:
   do s1; s2; s3; while ...
Since it can't tell whether that while is the terminator, or is another nested loop.
Now, you could have given a more measured, respectful reply and pointed these things out, instead of being condescending and patronising.
You might also have pointed out that C could have deprecated null statements consisting of a single ";", and required the more visible "{}", as some compilers can be requested to do. Since such a ";" can instroduce very subtle errors that are hard to spot.
That the option exists suggests that some people do have trouble with it. But your attitude appears to be the arrogant one that because it is technically unambiguous, then ANYONE should be able to spot such errors.
And if they can't then they should spend more time studying manuals, choose a different language, or give up coding altogether.
In your book, it's fine to write expressions like this:
   a + b & c * d == f < g | h ? i ^ j : k && l
without parentheses, because the C grammar is 100% unambiguous in what it means.
That is really not helpful.