| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 596
|
| Notify-List |
|
| Category | errata
|
| Synopsis | ambiguous operands in expressions (A.8.3)
|
| State | open
|
| Class | errata-discuss
|
| Arrival-Date | Jul 19 2004
|
| Originator | Eric Mahurin
|
| Release |
|
| Environment |
|
| Description |
In annex A, the expression alternative for a binary operations is defined as: expression binary_operator expression This kind of recursive definition causes quite a bit of ambiguity as to what the left and right expressions are for each binary_operator in an expression. I suggest that expression be defined in terms of the operator precedence so that the BNF makes it clear as to what are the operands of each operator. Here's my suggested BNF: expression ::= conditional_expression | STRING conditional_expression : logical_or_expression [ "?" attrs expression ":" expression ] logical_or_expression ::= logical_and_expression { "||" logical_and_expression } logical_and_expression ::= bitwise_or_expression { "&&" bitwise_or_expression } bitwise_or_expression ::= bitwise_xor_expression { "|" bitwise_xor_expression } bitwise_xor_expression ::= bitwise_and_expression { ("^"|"~^"|"^~") bitwise_and_expression } bitwise_and_expression ::= equality_expression { "&" equality_expression } equality_expression ::= inequality_expression { ("=="|"!="|"==="|"!==") inequality_expression } inequality_expression ::= shift_expression { (">="|"<"|"<="|">") shift_expression } shift_expression ::= additive_expression { ("<<"|">>"|"<<<"|">>>") additive_expression } additive_expression ::= multiplicative_expression { ("+"|"-") multiplicative_expression } multiplicative_expression ::= exponential_expression ( ("*"|"/"|"%") exponential_expression } exponential_expression ::= unary_expression { "**" unary_expression } unary_expression ::= ( "+" | "-" | "!" | "~" | "&" | "~&" | "|" | "~|" | "^" | "~^" | "^~" ) unary_expression | primary I think you should also consider just using "expression" for definitions constant_expression and module_path_expression with footnotes describing what the leaf nodes should be. That way this entire thing doesn't need to be redefined. |
| Fix |
Unknown |
| Audit-Trail |
From: Shalom.Bresticker@freescale.com To: eric_mahurin@yahoo.com Cc: etf-bugs@boyd.com Subject: Re: errata/596: ambiguous operands in expressions (A.8.3) Date: Tue, 20 Jul 2004 17:35:52 +0300 (IDT) After looking at this, I think the suggestion is much more confusing than the current BNF. Shalom > Here's my suggested BNF: > > expression ::= conditional_expression | STRING > > conditional_expression : logical_or_expression [ "?" attrs expression ":" expression ] > > logical_or_expression ::= logical_and_expression { "||" logical_and_expression } > > logical_and_expression ::= bitwise_or_expression { "&&" bitwise_or_expression } > > bitwise_or_expression ::= bitwise_xor_expression { "|" bitwise_xor_expression } > > bitwise_xor_expression ::= bitwise_and_expression { ("^"|"~^"|"^~") bitwise_and_expression } > > bitwise_and_expression ::= equality_expression { "&" equality_expression } > > equality_expression ::= inequality_expression { ("=="|"!="|"==="|"!==") inequality_expression } > > inequality_expression ::= shift_expression { (">="|"<"|"<="|">") shift_expression } > > shift_expression ::= additive_expression { ("<<"|">>"|"<<<"|">>>") additive_expression } > > additive_expression ::= multiplicative_expression { ("+"|"-") multiplicative_expression } > > multiplicative_expression ::= exponential_expression ( ("*"|"/"|"%") exponential_expression } > > exponential_expression ::= unary_expression { "**" unary_expression } > > unary_expression ::= ( "+" | "-" | "!" | "~" | "&" | "~&" | "|" | "~|" | "^" | "~^" | "^~" ) unary_expression > | primary -- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Reuse Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential Proprietary From: Stefen Boyd <stefen@boyd.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/596: ambiguous operands in expressions (A.8.3) Date: Mon, 26 Jul 2004 08:19:03 -0700 >Date: Tue, 20 Jul 2004 12:18:19 -0700 >From: mail <mail@boyd.com> >Subject: Failed bug submission from Eric Mahurin <eric_mahurin@yahoo.com>, >eric_mahurin@yahoo > > >From eric_mahurin@yahoo.com Tue Jul 20 12:18:17 2004 >Received: from web41114.mail.yahoo.com (web41114.mail.yahoo.com >[66.218.93.30]) > by wa.boyd.com (8.12.8/8.12.8) with SMTP id i6KJIHKk012268 > for <etf-bugs@boyd.com>; Tue, 20 Jul 2004 12:18:17 -0700 >Message-ID: <20040720192153.41267.qmail@web41114.mail.yahoo.com> >Received: from [66.90.167.158] by web41114.mail.yahoo.com via HTTP; Tue, >20 Jul 2004 12:21:53 PDT >Date: Tue, 20 Jul 2004 12:21:53 -0700 (PDT) >From: Eric Mahurin <eric_mahurin@yahoo.com> >Subject: Re: errata/596: ambiguous operands in expressions (A.8.3) >To: Shalom.Bresticker@freescale.com >Cc: etf-bugs@boyd.com >In-Reply-To: <Pine.GSO.4.10.10407201734510.15991-100000@eagle> >MIME-Version: 1.0 >Content-Type: text/plain; charset=us-ascii > >Shalom, > >It may be more confusing, but at least it conveys what >the operator operands are and is not ambiguous. For >example, try the expression a*b+c&d/e<f&&g==h. The >current BNF allows this to be interpreted a variety of >ways, but only one gives the correct meaning >(following the operator precedence). > >In general, what are the goals of the BNF? Here are >some things I can think of: > >1. allow all valid syntax (a given). > >2. disallow as much invalid syntax as possible. To >not complicate things too much some syntax issues >could be handled with verbage and treated as a >semantic issue instead of a syntactic issue. For >example a function_statement is defined as a >statement, but is qualified with certain rules from >10.3.4. > >3. Structure the syntax in a meaningful way. For >example, attributes could (almost) syntactically be >treated like optional separators between statements >and operators or almost comments/whitespace, but >semantically, they should be associated with what >follows, so that's where they are specified in the >BNF. > >4. Have no ambiguity so that every component of every >rule is clearly defined. It should be clear as to >what alternatives ("|"), options ("[]"), and number of >repetitions ("{}") are taken for any valid syntax. > >I assume #1 and #2 above are goals. I hope #3 and #4 >are also. To use this BNF directly as a basis for a >parser, I think all of these goals need to be met. > >The current BNF for "expression" utterly fails these >#3 and #4 goals. scalar_timing_check_expression >(errata/237) also fails similarly. I've found a few >others that fail goal #4 and haven't mentioned those - >they are not as involved. > >- Eric > >--- Shalom.Bresticker@freescale.com wrote: > > After looking at this, I think the suggestion is > > much more confusing than the current BNF. > > > > Shalom > > > > > > > Here's my suggested BNF: > > > > > > expression ::= conditional_expression | STRING > > > > > > conditional_expression : logical_or_expression [ > > "?" attrs expression ":" expression ] > > > > > > logical_or_expression ::= logical_and_expression { > > "||" logical_and_expression } > > > > > > logical_and_expression ::= bitwise_or_expression { > > "&&" bitwise_or_expression } > > > > > > bitwise_or_expression ::= bitwise_xor_expression { > > "|" bitwise_xor_expression } > > > > > > bitwise_xor_expression ::= bitwise_and_expression > > { ("^"|"~^"|"^~") bitwise_and_expression } > > > > > > bitwise_and_expression ::= equality_expression { > > "&" equality_expression } > > > > > > equality_expression ::= inequality_expression { > > ("=="|"!="|"==="|"!==") inequality_expression } > > > > > > inequality_expression ::= shift_expression { > > (">="|"<"|"<="|">") shift_expression } > > > > > > shift_expression ::= additive_expression { > > ("<<"|">>"|"<<<"|">>>") additive_expression } > > > > > > additive_expression ::= multiplicative_expression > > { ("+"|"-") multiplicative_expression } > > > > > > multiplicative_expression ::= > > exponential_expression ( ("*"|"/"|"%") > > exponential_expression } > > > > > > exponential_expression ::= unary_expression { "**" > > unary_expression } > > > > > > unary_expression ::= ( "+" | "-" | "!" | "~" | "&" > > | "~&" | "|" | "~|" | "^" | "~^" | "^~" ) > > unary_expression > > > | primary > > > > -- > > Shalom Bresticker > > Shalom.Bresticker @freescale.com > > Design & Reuse Methodology > > Tel: +972 9 9522268 > > Freescale Semiconductor Israel, Ltd. > > Fax: +972 9 9522890 > > POB 2208, Herzlia 46120, ISRAEL > > Cell: +972 50 5441478 > > > > [ ]Freescale Internal Use Only [ ]Freescale > > Confidential Proprietary > > > > > > > > > >__________________________________ >Do you Yahoo!? >Vote for the stars of Yahoo!'s next ad campaign! >http://advision.webevents.yahoo.com/yahoo/votelifeengine/ -------------------- Stefen Boyd Boyd Technology, Inc. stefen@BoydTechInc.com (360)666-6957 www.BoydTechInc.com |
| Unformatted |
|
Hosted by Boyd Technology