| Number | 462
|
| Category | errata
|
| Synopsis | A.1.1: " < file_path_spec > " should be "file_path_spec"
|
| State | lrmdraft
|
| Class | errata-simple
|
| Arrival-Date | Sep 04 2003
|
| Originator | Shalom.Bresticker@motorola.com
|
| Release | 2001b: Syntax 13-2 & 13-3, A.1.1
|
| Environment |
|
| Description |
In Syntax 13-2 and 13-3 and in A.1.1: CHANGE " include_statement = include <file_path_spec> ; " TO " include_statement = include file_path_spec ; " The angle brackets should not be there. The keyword "include" and the semicolon should be bold. This issue is a spinoff from #175 Part A, in order to approve it from 1364-2001c. |
| Fix |
In Syntax 13-2 and 13-3 and in A.1.1: CHANGE
" include_statement = include < file_path_spec > ; "
TO
" include_statement = include file_path_spec ; "
The angle brackets should not be there. The keyword "include" and the semicolon should be bold. |
| Audit-Trail |
From: Francoise Martinolle <fm@cadence.com> To: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com Subject: Re: errata/462: A.1.1: "<file_path_spec" should be "file_path_spec" Date: Thu, 04 Sep 2003 11:37:37 -0400 Shalom, Also I noticed that file_path is not defined. file_path_spec ::= file_path include_statement ::= include <file_path_spec> ; Francoise ' >In Syntax 13-2 and 13-3 and in A.1.1: > >CHANGE > > " include_statement = include <file_path_spec> ; " > >TO > > " include_statement = include file_path_spec ; " > >The angle brackets should not be there. >The keyword "include" and the semicolon should be bold. > >This issue is a spinoff from #175 Part A, >in order to approve it from 1364-2001c. From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: RE: errata/462: A.1.1: "<file_path_spec" should be "file_path_spec" Date: Thu, 4 Sep 2003 09:16:56 -0700 According to the notes below Syntax 13-2, the file_path is a "file system- specific notation to specify an absolute or relative path ...". On the other hand, these notes and the examples assume a slash-style (.../...) hierarchy delimiter. And they seem to prescribe a variety of specific "shortcuts/wildcards". Also, the note in 13.7.1 uses a <> notation around library_name. Should these <> be removed, too? Maybe the <> in both cases are not bugs, but are metalanguage notation -- like [] and {} -- used to indicate system-specific notation that is not (and should not be) specified by the LRM? -- Brad From: Shalom.Bresticker@motorola.com To: Francoise Martinolle <fm@cadence.com> Cc: etf-bugs@boyd.com Subject: Re: errata/462: A.1.1: "<file_path_spec" should be "file_path_spec" Date: Fri, 5 Sep 2003 12:02:42 +0300 (IDT) > Also I noticed that file_path is not defined. > > file_path_spec ::= file_path > include_statement ::= include <file_path_spec> ; That is correct. It is one of those terms which does not have a formal syntactic definition. It is discussed in 13.2.1. There are a few other terms like that in the BNF. I would have deleted the line > file_path_spec ::= file_path except that we want to say that a file_path_spec may appear with or without quotation marks, so that we will get file_path_spec ::= file_path | "file_path" Issue #175 deals with defining when the quotation marks are required. -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 From: Shalom.Bresticker@motorola.com To: Brad Pierce <Brad.Pierce@synopsys.com> Cc: etf-bugs@boyd.com Subject: RE: errata/462: A.1.1: "<file_path_spec>" should be "file_path_spec" Date: Fri, 5 Sep 2003 12:15:32 +0300 (IDT) > According to the notes below Syntax 13-2, the file_path is a "file system- > specific notation to specify an absolute or relative path ...". > > On the other hand, these notes and the examples assume a > slash-style (.../...) hierarchy delimiter. And they seem to prescribe > a variety of specific "shortcuts/wildcards". Yes, issue #175 deals with that, too. > Also, the note in 13.7.1 uses a <> notation around library_name. > Should these <> be removed, too? There "library_name" does not refer to a specific BNF construct. It is indeed a meta-language notation, as you say below. > Maybe the <> in both cases are not bugs, but are metalanguage notation -- > like [] and {} -- used to indicate system-specific notation that is not > (and should not be) specified by the LRM? The differences are that the term "file_name_spec" is used several times in the BNF, but only once with <>. There it is simply a mistake. We could write file_name_spec ::= <file_name> | "<file_name>" because "file_name" is not used anywhere else in the BNF, but the <> notation is not part of the BNF and not used anywhere else, in contrast to [] and {}, which have syntactic meanings to the parser. I think the proposal is correct, but of course incomplete and issue #175 has to fill in the holes. Shalom -- Shalom Bresticker Shalom.Bresticker@motorola.com Design & Reuse Methodology Tel: +972 9 9522268 Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478 |
| Unformatted |
|
Hosted by Boyd Technology