Path: csiph.com!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: question about linker Date: Sat, 07 Dec 2024 13:38:02 -0800 Organization: None to speak of Lines: 148 Message-ID: <87msh7xjgl.fsf@nosuchdomain.example.com> References: <20241129142810.00007920@yahoo.com> <20241129161517.000010b8@yahoo.com> <87ldwx10gv.fsf@bsb.me.uk> <86ser1kgp5.fsf@linuxsc.com> <87ldwtzlc0.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Sat, 07 Dec 2024 22:38:04 +0100 (CET) Injection-Info: dont-email.me; posting-host="4404786bd9d9b4f8a090df7e3f4592f8"; logging-data="3497318"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+1JeHcFeFUqptyklYdIrht" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:LZMgg4rLXW46a+NCOwYarFSfTc8= sha1:N+xwFKuMNyfMWeBB7QlA9Lwu/CQ= Xref: csiph.com comp.lang.c:389499 Bart writes: > 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'. OK, it was a mistake. Someone pointed it out. And you took offense at that for some reason. > It says something however when I actually believed that that code was > valid, because the compiler appeared to say so. It doesn't say anything interesting. >> 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? It is. Don't lie. > 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? Nobody said that. Don't lie. > Is it just to avoid admitting that I might have a point? What point is that? That C can be confusing? We all know that. >>> 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? If I'm a parser, then I was written to follow the grammar, which happens to be unambiguous. If I'm a human reader, 99+% of the time the code will have been formatted to avoid any apparent ambiguity. In a do-while loop, the last line typically of the form "} while (cond);", and the closing "}" matches the opening "do {". If I somehow miss the semicolon, the fact that the following line is not a "{" and is at the same indentation is a strong clue. Some coding styles might use: do { statements; } while (cond); but even that isn't difficult to understand. Some years ago, I wrote some C code that deliberately made the "while (cond)" of a do/while loop appear to be part of a while loop. It was for a submission to the IOCCC . If you go out of your way to make C code appear ambiguous, it will appear ambiguous (to a human reader if not to a compiler). I rarely do that. You do it far too often. > 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. [snip] > So it can't work in a syntax which allows N statements in a block: > > do s1; s2; s3; while ... C doesn't allow that, so it doesn't matter. > Since it can't tell whether that while is the terminator, or is > another nested loop. You take the fact that a do/while or while loop controls a single statement, and distort it with irrelevancies to make it seem like a problem. [...] > 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. I don't know of any such compiler options. But apparently you don't use it yourself, since you've recently complained about the need to emit "L:;" in generated C code. If you used that option, you'd have to emit "L:{}". You invent a problem that apparently doesn't even affect you, and pretend that it must affect others. > 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. No, Janis merely stated that the syntax is unambiguous. Which, as you know, it is. > 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. Nobody said that. Don't lie. Yes, C can be confusing. When have you ever written anything with the intent of clearing up the confusion? -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */