Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: question about linker
Date: Wed, 11 Dec 2024 16:28:28 +0100
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <vjcb2s$1jcad$4@dont-email.me>
References: <vi54e9$3ie0o$1@dont-email.me>
 <87plmfu2ub.fsf@nosuchdomain.example.com> <vi9jk4$gse4$1@dont-email.me>
 <vi9kng$gn4c$1@dont-email.me> <87frnbt9jn.fsf@nosuchdomain.example.com>
 <viaqh0$nm7q$1@dont-email.me> <877c8nt255.fsf@nosuchdomain.example.com>
 <viasv4$nm7q$2@dont-email.me> <vibr1l$vvjf$1@dont-email.me>
 <vic73f$1205f$1@dont-email.me> <20241129142810.00007920@yahoo.com>
 <vicfra$13nl4$1@dont-email.me> <20241129161517.000010b8@yahoo.com>
 <vicque$15ium$2@dont-email.me> <vid110$16hte$1@dont-email.me>
 <vifcll$1q9rj$1@dont-email.me> <vifiib$1s07p$1@dont-email.me>
 <87ldwx10gv.fsf@bsb.me.uk> <vimtt4$27vv$1@dont-email.me>
 <86ser1kgp5.fsf@linuxsc.com> <vit69t$1qfgg$1@dont-email.me>
 <87ldwtzlc0.fsf@nosuchdomain.example.com> <vitjgg$1tukq$2@dont-email.me>
 <vj1bss$325uo$1@dont-email.me> <vj1h4i$335q1$2@dont-email.me>
 <vj1mhi$34p7h$1@dont-email.me> <vj1prj$35je4$1@dont-email.me>
 <vj7dup$he7i$1@dont-email.me> <slrnvlik4j.ns4.ike@iceland.freeshell.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 11 Dec 2024 16:28:28 +0100 (CET)
Injection-Info: dont-email.me; posting-host="2219d0e81fc8abda50710a06e8939fe0";
	logging-data="1683789"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18nA0QJpd/9eAMFFVppZ+mw0BFT3V5GD+0="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:A5hWX3Lzo15/PO+MHrBBPWTruQ0=
Content-Language: en-GB
In-Reply-To: <slrnvlik4j.ns4.ike@iceland.freeshell.org>
Bytes: 4069

On 11/12/2024 09:43, Ike Naar wrote:
> On 2024-12-09, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> An unambiguous grammar is something quite essential; how would you
>> parse code if it were ambiguous?
> 
> Here's an ambiguity in the C grammar:
> 
>      <statement>:
>          ...
>          <selection-statement>
>          ...
> 
>      <selection-statement>:
>          ...
>          if ( <expression> ) <statement>
>          if ( <expression> ) <statement> else <statement>
>          ...
> 
> The following selection-statement is grammatically ambiguous:
> 
>      if (E1) if (E2) S1 else S2
> 
> it has two possible parsings:
> 
>      if (E1) <statement> else S2
> 
>      where <statement> expands to
> 
>          if (E2) S1
> 
> or
> 
>      if (E1) <statement>
> 
>      where <statement> expands to
> 
>          if (E2) S1 else S2
> 
> The grammatical ambiguity is resolved by an additional rule in the
> 'Semantics' section for selection-statement:
> 
>    3 An else is associated with the lexically nearest preceding if that is
>      allowed by the syntax.
> 

Given that the resolution is in the "semantics" section rather than the 
"syntax" section, it might seem like a grammatical ambiguity.  But I 
don't think it is, technically - the syntax rules say that the set of 
tokens making up "if (E1) if (E2) S1 else S2" are valid syntax.  It is 
up to the semantics to determine what the code will do here.  (And the 
semantics are unambiguous.)

> gcc -Wall will issue a warning for such an ambiguous statement:
> 
>      warning: suggest explicit braces to avoid ambiguous 'else' [-Wdangling-else]

gcc is not warning about ambiguity - it is well specified exactly what 
the code means in the language.  It is warning because it might not be 
clear to the human reader and/or programmer.

Certainly such nested "if" statements without braces can be confusing to 
people, and they may require extra effort in a parser.  But they are not 
an ambiguity in the language.