Re: question about linker

On 07.12.2024 16:33, Bart wrote:

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.

See mine.

 

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.

Am I?

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

The fact I'm describing here is that you are repeatedly making up
things, construct unrealistic lunatic samples, and argument based
on them. There is little difference in whether you made a mistake
in your sample or not. In other words; you are often the source of
your confusion, homemade as we say. If you'd have formatted your
sample in a sensible way (as certainly all other people here would
have done) you'd instantly have seen your mistake and that the "C"
syntax structure isn't any problem at all.

 
It says something however when I actually believed that that code was
valid, because the compiler appeared to say so.

Huh?

 

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?

"for" what? - You mean, for me, for the audience here?

Why do you make things up again; of course in most languages some
language patterns are more obvious than others. (Please leave your
fantasy world and drop your pipe dreams if you want to seriously
discuss things here.)

 
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?

Who said that? - Again you make up things just for your argument.

An unambiguous grammar is something quite essential; how would you
parse code if it were ambiguous?

To what ([hypothetical] "some") grammar are you referring to?

If you mean the "C" grammar; what, concretely, you find to be
"convoluted"?

You postulate it as if the grammar were convoluted; more likely
it's just your personal problem with understanding formal syntax.

No one said, that everything is "100% obvious". An unambiguous
grammar is a precondition for for an understanding, though.

If you'd have your excerpts and samples formatted in a common
(non-lunatic) way then it should have been "100% obvious" even
to you.

 
Is it just to avoid admitting that I might have a point?

(Yet you haven't had one.)

 
 

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?

Because there's the '...' in between that answers that question.

 
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 you've got it?

 
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.

All that could be read from the various posts you've got or inferred
if you'd have spent a minimum of interest (instead of lashing out
with inappropriate examples, and your personal peculiarities).

Now, you could have given a more measured, respectful reply and pointed
these things out, instead of being condescending and patronising.

You've got all the facts and explanations (including samples) from
several sides (mine included) here.

(My patience, if constantly stressed, is of course limited.)

 
You might also have pointed out

I see that many folks here (me included) were and are trying to
explain things to you that you say would confuse you. - If from
the manifold replies you cannot see the substance, that's still
no justification to demand any specific sort of answer. How do
you think we know which formulation or detail might enlighten
you, especially given that you are constantly reluctant or even
unwilling to understand the presented answers.

that C could have deprecated null
statements consisting of a single ";",

Why should I have pointed that out?  (It isn't even my opinion.)

I've even put it in one of the (corrected and reformatted) sample;
for your convenience, this one:

  do
     while (cond)
        ;
  while (cond);

That's a clear structure, and the indented single semicolon is IMO
certainly not worse than

  do
     while (cond) {
     }
  while (cond);

(which, personally, I find to be inferior concerning readability).
I'd probably instead choose

  do {
     while (cond)
        ;
  } while (cond);

But this is anyway just a fragment (of limited value if one wants
to explain a sensible formatting).

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.

You obviously have that problem. - I certainly wouldn't go so far
extrapolating from you to other people.

 
That the option exists suggests that some people do have trouble with
it.

What option?

There's simple statements, and there's blocks of one or more simple
statements. There's also the empty statement. That's not any special
option that exists. It's a basic concept, in almost all languages I
know, to group 0..N statements together, or just write an empty one.

But your attitude appears to be the arrogant one that because it is
technically unambiguous, then ANYONE should be able to spot such errors.

Bullshit. Stop making up things and, honestly, start considering that
your attitude might be the problem (and things may clear up for you).

 
And if they can't then they should spend more time studying manuals,
choose a different language, or give up coding altogether.

If you'd have read (and understood) all replies to you then you'd
for example learned that it's a Good Thing to read a good textbook
about any language you use before you start programming with it.
And if there's anything that you don't understand ask folks (here
or elsewhere) who do understand; but you should at least spend a
minimum effort to understand the replies then.

If you intend to do a new project (and if you are responsible to
decide in that project context) choose the language most suited.

And of course you can code what you like without doing anything
sensible, established ways in your own toy or hobby projects;
just don't repeatedly and constantly complain about things you
obviously don't want to learn or understand.

 
In your book, it's fine to write expressions like this:
 
  a + b & c * d == f < g | h ? i ^ j : k && l

Stop making up things. That doesn't solve any question or issue,
and you are most certainly wrong in 98% of your imputations.

 
without parentheses, because the C grammar is 100% unambiguous in what
it means.

(You are a pathological case.)

 
That is really not helpful.

(I don't see anyone [from IT or CS sector] who could help you.)

Janis