Add Proposal | Add Analysis | Edit Class, Environment, or Release |
Number | 175
|
Category | errata
|
Synopsis | 13.2: file_path_spec syntax and related issues
|
State | open
|
Class | errata-discuss
|
Arrival-Date | Oct 27 2002
|
Originator | Shalom Bresticker <Shalom.Bresticker@motorola.com>
|
Release | 2001b: 13.2
|
Environment |
|
Description |
file_path_spec is used in library declarations, Issues: A. Whereas in library_declaration BNF, it appears simply as file_path_spec, it appears as <file_path_spec> in include_statement. There does not seem to be any reason for the angle brackets. B. The production file_path_spec ::= file_path appears to serve no useful purpose. The two appear to be synonymous. file_path seems to be used only here. C. The NOTE following Syntax 13-2 starts, "The file_path uses file system-specific notation to specify an absolute or relative path to a particular file or set of files." Yet it talks about "/". Is that really common to all systems? D. Related to errata/99 about library keywords, note that "incdir" can be used only as "-incdir", and the "-" may only be followed by "incdir", making it even less of a "general" keyword. E. Can there be white space between "-" and "incdir"? F. There should be examples of use of "-incdir" and of "include". G. See related issues 99, 135. |
Fix |
In Syntax 13-2, Syntax 13-3 and section A.1.1 Change: include_statement ::= include <file_path_spec>; To: include_statement ::= file_path_spec; | "file_path_spec" Add Note 3 under NOTES just after Syntax 13-2: The " " in file_path_spec are optional if the file_path only contains the characters a-z, A-Z, 0-9 or . , otherwise they are required. In the example in section 13.7.3 Change: library lib2 "/proj/lib1/foo.v"; To: library lib2 "/proj/lib1/fo,o.v"; //" " required due to , in file name |
Audit-Trail |
From: Dennis Marsa <drm@xilinx.com> To: Shalom Bresticker <Shalom.Bresticker@motorola.com> Cc: etf-bugs@boyd.com Subject: Re: errata/175: 13.2: file_path_spec syntax and related issues Date: Mon, 28 Oct 2002 08:21:06 -0700 >Category: errata >Confidential: no >Originator: Dennis Marsa <drm@xilinx.com> >Release: 2001b >Class: TBD >Description: Shalom Bresticker wrote: > > Precedence: bulk > > >Number: 175 > >Category: errata > >Originator: Shalom Bresticker <Shalom.Bresticker@motorola.com> > >Environment: > >Description: > > file_path_spec is used in library declarations, > > Issues: > > A. Whereas in library_declaration BNF, it appears simply as > file_path_spec, it appears as <file_path_spec> in include_statement. > There does not seem to be any reason for the angle brackets. I think we should consider whether file_path_spec's should be enclosed in some type of delimiter such as <> or "". Without them, files containing e.g. whitespace, commas (','), semicolons (';') would not be possible to reference since those characters are currently the only way to delimit filenames. Note that the `include directive requires the included file be enclosed in "". Dennis From: Shalom.Bresticker@motorola.com To: Dennis Marsa <drm@xilinx.com> Cc: etf-bugs@boyd.com Subject: Re: errata/175: 13.2: file_path_spec syntax and related issues Date: Mon, 28 Oct 2002 19:54:49 +0200 (IST) >Category: errata >Confidential: no >Originator: Shalom.Bresticker@motorola.com >Release: 2001b >Class: TBD >Description: Since there are already examples without delimiters, maybe the delimiters could be optional, useful for the casses you mention. On Mon, 28 Oct 2002, Dennis Marsa wrote: > I think we should consider whether file_path_spec's should be > enclosed in some type of delimiter such as <> or "". > > Without them, files containing e.g. whitespace, commas (','), > semicolons (';') would not be possible to reference since > those characters are currently the only way to delimit filenames. > > Note that the `include directive requires the included file be > enclosed in "". From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/175: 13.2: file_path_spec syntax and related issues Date: Thu, 9 Jan 2003 23:17:12 +0200 (IST) Also see mail from Jayram Bhasker on May 3, 2002, in which he points out that example of file_path_spec in library statement in example in 13.2.1 is without double quotes around the file_path_spec, whereas in the example in 13.7.3, there ARE double quotes. From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/175: 13.2: file_path_spec syntax and related issues Date: Thu, 9 Jan 2003 23:30:08 +0200 (IST) I just noticed that that mail (I don't have access to the exact URL right now) started an entire thread. Probably have to split the discussion into subissues. Anyway, among other things, in that thread, Cliff claimed that the double quotes should have been deleted (there was a vote), and that the <> in the include syntax is a typo. Dennis said that will be a problem with names with special characters, such as spaces or commas. > Also see mail from Jayram Bhasker on May 3, 2002, in which he points out that > example of file_path_spec in library statement in example in 13.2.1 is without > double quotes around the file_path_spec, whereas in the example in 13.7.3, there > ARE double quotes. Shalom From: Shalom.Bresticker@motorola.com To: etf-bugs@boyd.com Cc: Subject: Re: errata/175: PROPOSAL - 13.2: file_path_spec syntax and related issues Date: Tue, 14 Jan 2003 05:35:18 +0200 (IST) Does this proposal address all issues raised in 175? Probably not. > include_statement ::= file_path_spec; | "file_path_spec" What about semicolon if quotes are used? From: Anders Nordstrom <asic@sympatico.ca> To: <etf-bugs@boyd.com> Cc: Subject: Re: errata/175: PROPOSAL - 13.2: file_path_spec syntax and related issues Date: Tue, 14 Jan 2003 21:26:02 -0500 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3125424363_17178000 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable The missing semicolon was a typo. Update the proposal to: include_statement ::=3D file_path_spec; | "file_path_spec"; This addresses part A. Part B is addressed by errata/99 and part D by errata/135. Part C: Absolute and relative paths are common terms. I am OK with =B3/=B2, wha= t is a more common name for the top directory or root? Part E: errata/99 proposes a list of special keywords. Syntax 13-2 already lists =ADincdir as one word (the =AD is bold as well). Regards, Anders On 1/13/03 10:40 PM, "Shalom.Bresticker@motorola.com" <Shalom.Bresticker@motorola.com> wrote: > Precedence: bulk >=20 > The following reply was made to PR errata/175; it has been noted by GNATS= . >=20 > From: Shalom.Bresticker@motorola.com > To: etf-bugs@boyd.com > Cc: =20 > Subject: Re: errata/175: PROPOSAL - 13.2: file_path_spec syntax and relat= ed > issues > Date: Tue, 14 Jan 2003 05:35:18 +0200 (IST) >=20 > Does this proposal address all issues raised in 175? Probably not. > =20 >> > include_statement ::=3D file_path_spec; | "file_path_spec" > =20 > What about semicolon if quotes are used? > =20 --B_3125424363_17178000 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable ssues <FONT FACE=3D"Verdana">The missing semicolon was a typo. Update the proposal = to: <FONT FACE=3D"Monaco">include_statement ::=3D file_path_spec; | &quo= t;file_path_spec"; <FONT FACE=3D"Verdana"> This addresses part A. Part B is addressed by errata/99 and part D by errat= a/135. Part C: Absolute and relative paths are common terms. I am OK with “/= ”, what is a more common name for the top directory or root? Part E: errata/99 proposes a list of special keywords. Syntax 13-2 already = lists –incdir as one word (the – is bold as well). Regards, Anders On 1/13/03 10:40 PM, "Shalom.Bresticker@motorola.com" <Shalom.= Bresticker@motorola.com> wrote: <FONT FACE=3D"Monaco">Precedence: bulk<FONT FACE=3D"Monaco"> --B_3125424363_17178000-- From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: Anders Nordstrom <asic@sympatico.ca> Cc: etf-bugs@boyd.com Subject: Re: errata/175: PROPOSAL - 13.2: file_path_spec syntax andrelated issues Date: Wed, 15 Jan 2003 09:22:15 +0200 Resend: Anders Nordstrom wrote: > The missing semicolon was a typo. Update the proposal to: > > > include_statement ::= file_path_spec; | "file_path_spec"; > > This addresses part A. > > Part B is addressed by errata/99 and part D by errata/135. > > > > Part C: Absolute and relative paths are common terms. I am OK with "/", > what is a more common name for the top directory or root? > > > > Part E: errata/99 proposes a list of special keywords. > Syntax 13-2 already lists -incdir as one word (the - is bold as well). From: Shalom.Bresticker@motorola.com To: Anders Nordstrom <asic@sympatico.ca> Cc: etf-bugs@boyd.com Subject: Re: errata/175: PROPOSAL - 13.2: file_path_spec syntax andrelated issues Date: Fri, 11 Apr 2003 14:28:03 +0300 (IDT) The original mail on this is quoted at the bottom. > Date: Wed, 15 Jan 2003 09:22:15 +0200 > Anders Nordstrom wrote: > > The missing semicolon was a typo. Update the proposal to: > > include_statement ::= file_path_spec; | "file_path_spec"; > > This addresses part A. Since file_path_spec appears 5 times and file_path only once, I suggest: A,B: include_statement ::= include file_path_spec ; ('include' and ';' in bold) file_path_spec ::= file_path | "file_path" (double-quotes are real) > > Part B is addressed by errata/99 99 talks about keywords. I don't see the connection. > > and part D by errata/135. Again, what is the connection? > > Part C: Absolute and relative paths are common terms. I am OK with "/", > > what is a more common name for the top directory or root? What about systems which use \ instead of / ? > > Part E: errata/99 proposes a list of special keywords. > > Syntax 13-2 already lists -incdir as one word (the - is bold as well). That was exactly my question. Can there be a space between - and incdir? Anders also suggested adding the following: "Add Note 3 under NOTES just after Syntax 13-2: The " " in file_path_spec are optional if the file_path only contains the characters a-z, A-Z, 0-9 or . , otherwise they are required." What about characters _-/\?* ? Most of these appear in examples in the LRM. Shalom Original mail: > Date: Sun, 27 Oct 2002 18:06:51 +0200 > From: Shalom Bresticker <Shalom.Bresticker@motorola.com> > Subject: errata/175: 13.2: file_path_spec syntax and related issues > > file_path_spec is used in library declarations, > > Issues: > > A. Whereas in library_declaration BNF, it appears simply as > file_path_spec, it appears as <file_path_spec> in include_statement. > There does not seem to be any reason for the angle brackets. > > B. The production file_path_spec ::= file_path appears to serve no > useful purpose. The two appear to be synonymous. file_path seems to be > used only here. > > C. The NOTE following Syntax 13-2 starts, > "The file_path uses file system-specific notation to specify an absolute > or relative path to a particular file or set of files." > Yet it talks about "/". Is that really common to all systems? > > D. Related to errata/99 about library keywords, note that "incdir" can > be used only as "-incdir", and the "-" may only be followed by "incdir", > making it even less of a "general" keyword. > > E. Can there be white space between "-" and "incdir"? > > F. There should be examples of use of "-incdir" and of "include". > > G. See related issues 99, 135. -- 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 <Shalom.Bresticker@motorola.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/175: Paths in library mapping rules (fwd) Date: Sun, 20 Jul 2003 09:33:00 +0300 ---------- Forwarded message ---------- Date: Wed, 16 Jul 2003 19:28:37 -0400 (EDT) From: Steven Sharp <sharp@cadence.com> To: etf@boyd.com Subject: Re: Paths in library mapping rules During the last ETF meeting, I was asked about the handling of quoted and unquoted file names in library mapping files in the NC-Verilog implementation. I have made some inquiries, and here is what I was told: ------------- Begin Forwarded Message ------------- Steve: Funny (or coincidental) that you should ask since I just fixed up the lib.map parser wrt handling names in double quotes. For any name (library name, file name, cell name, instance name, etc.) we require quoting if 1) it contains /* Note: */ can appear in a name without quoting, it only ends a comment string when preceded by a non-quoted /* 2) it contains any "special" characters: <space> , ( ) ' < > ` \ } { = / & | ~ : ; ] [ Note: if a name contains any of these other than space, it can be either quoted or start with \ to indicate an escaped name. It does not appear that currently I allow <tab> in this list of special characters (for quoting only)...I think I need to add it. Should \n also be included or is that too goofy? I should point out that keywords can not be quoted (it will mess up the parser if you quote them!) We do support the funky Windows backslash directory delimiter (OK, I should say that the code attempts to support this, but I have no idea if any tests were run on windows to check, I do think PV runs some tests on windows, though). ------------- End Forwarded Message ------------- Steven Sharp sharp@cadence.com |
Unformatted |
|
Hosted by Boyd Technology