Subject: Re: [sv-ec] System include proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Mar 11 2003 - 12:52:25 PST
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 108
> From owner-sv-ec@server.eda.org Tue Mar 11 11:53:25 2003
>
> Hi Jay,
>
> I agree with the bulk of your proposal. I do however have some questions in the
> case of the <> syntax.
>
>
> According to the proposal, when the <> include syntax is specified only the
> "system-wide installation" is searched. In general, one would expect that
> only a filename would need to be specified in this situation.
>
> Do you foresee situations where an absolute or relative path would be
> useful here?
>
> It appears that a relative path specified with the <> syntax only makes
> sense if I am currently sitting in this "system-wide installation".
>
> What happens if I specify an absolute path that happens to not be part of
> this "system-wide installation"?
>
> Comments on suggestions made by others on the system-include proposal
>
> - Kevin's suggestion for using []
>
> The reasoning behind this suggestion appears to be flawed. If the concept
> of a Verilog system include file is adopted then all vendors that provide
> tools that parse Verilog files will need to provide these standard include
> files in their release package. The use of <> is a natural choice for these
> installation specific files. Vendors already provide OS specific releases.
> If a vendor wants to provide other "tool specific" includes these can also
> reside in this same release area. The "system specific" files that Kevin
> refers to correspond to the standard include files required by the LRM.
I would like (as Stephen Williams suggests) that <> behave exactly like the
C <> so that I can migrate C code through an SV translator. As you say the
directory searched for <> would probably be supplied by vendors, but as a
user I would like to be able to redirect it to my own version if necessary
- E.g. if I was Sun Micro and was testing a new machine/OS in simulation
(which vendors can't support yet).
Overloading <> for tool-specific includes makes it difficult to handle any
file-name clashes that turn up.
NB: you can have it that using <> searches the OS-specific directories first
then the tool-specific and then the users directories, in which case [] would
only be needed if there is a name clash (it would search tool-specific
directories first).
Kev.
> - Stephen William's suggestion for following the C-standard
>
> I did a google web search and found a copy of what appears to be the
> C-standard. Stephen is correct in stating that the C-standard is somewhat
> vague in its search path description. The following is an excerpt
> "...searches a sequence of implementation-defined places...". I don't think
> that we want to follow this approach and leave it up to the vendors to
> decide what the search order should be. The LRM should state the search order
> rules.
>
> Some C implementations allow <> to refer to user-written include files. When
> the user inadvertently chooses the same filename that happens to correspond
> to a file contained in the installation area the user-written file gets
> ignored. Debugging this situation can be time-consuming. Avoiding this
> situation, as you have done in your proposal, appears to be an improvement.
>
> - The C standard
>
> I attached the relevant section from the C-standard document located at
>
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm
>
> Neil
>
>
>
> > X-Unix-From: lawrence@cadence.com Mon Mar 10 04:52:52 2003
> > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> > content-class: urn:content-classes:message
> > MIME-Version: 1.0
> > Subject: [sv-ec] System include proposal
> > Date: Mon, 10 Mar 2003 07:52:04 -0500
> > X-MS-Has-Attach: yes
> > X-MS-TNEF-Correlator:
> > Thread-Topic: System include proposal
> > Thread-Index: AcLnA9lXonDf3ShqR2CJ8GTXe+LgMg==
> > From: "Jay Lawrence" <lawrence@cadence.com>
> > To: <sv-ec@eda.org>
> > X-Received: By mailgate.Cadence.COM as EAA00677 at Mon Mar 10 04:52:04 2003
> >
> >
> > Attached is the proposal on a system-wide include mechanism.
> >
> > Jay
> >
> >
> >
> >
> > ===================================
> > Jay Lawrence
> > Architect - Functional Verification
> > Cadence Design Systems, Inc.
> > (978) 262-6294
> > lawrence@cadence.com
> > ===================================
----------
X-Sun-Data-Type: text
X-Sun-Data-Name: c_standard.include
X-Sun-Encoding-Info: 7bit
Content-MD5: 4QNsdzz7MfAmc1a8Jb+fbw==
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 114
[ISO/] [IEC] JTC1/SC22/WG14 N843
Programming languages -- C
6.10.2 Source file inclusion
Constraints
[#1] A #include directive shall identify a header or source
file that can be processed by the implementation.
Semantics
[#2] A preprocessing directive of the form
# include <h-char-sequence> new-line
searches a sequence of implementation-defined places for a
header identified uniquely by the specified sequence between
the < and > delimiters, and causes the replacement of that
directive by the entire contents of the header. How the
places are specified or the header identified is
implementation-defined.
[#3] A preprocessing directive of the form
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire
contents of the source file identified by the specified
sequence between the " delimiters. The named source file is
searched for in an implementation-defined manner. If this
search is not supported, or if the search fails, the
directive is reprocessed as if it read
# include <h-char-sequence> new-line
with the identical contained sequence (including >
characters, if any) from the original directive.
[#4] A preprocessing directive of the form
# include pp-tokens new-line
(that does not match one of the two previous forms) is
permitted. The preprocessing tokens after include in the
directive are processed just as in normal text. (Each
identifier currently defined as a macro name is replaced by
____________________
132As indicated by the syntax, a preprocessing token shall
not follow a #else or #endif directive before the
terminating new-line character. However, comments may
appear anywhere in a source file, including within a
preprocessing directive.
6.10.1 Language 6.10.2
WG14/N843 Committee Draft -- August 3, 1998 165
its replacement list of preprocessing tokens.) The
directive resulting after all replacements shall match one
of the two previous forms.133) The method by which a
sequence of preprocessing tokens between a < and a >
preprocessing token pair or a pair of " characters is
combined into a single header name preprocessing token is
implementation-defined.
[#5] The implementation shall provide unique mappings for
sequences consisting of one or more letters or digits (as
defined in 5.2.1) followed by a period (.) and a single
letter. The first character shall be a letter. The
implementation may ignore the distinctions of alphabetical
case and restrict the mapping to eight significant
characters before the period.
[#6] A #include preprocessing directive may appear in a
source file that has been read because of a #include
directive in another file, up to an implementation-defined
nesting limit (see 5.2.4.1).
[#7] EXAMPLE 1 The most common uses of #include
preprocessing directives are as in the following:
#include <stdio.h>
#include "myprog.h"
[#8] EXAMPLE 2 This illustrates macro-replaced #include
directives:
#if VERSION == 1
#define INCFILE "vers1.h"
#elif VERSION == 2
#define INCFILE "vers2.h" // and so on
#else
#define INCFILE "versN.h"
#endif
#include INCFILE
Forward references: macro replacement (6.10.3).
____________________
133Note that adjacent string literals are not concatenated
into a single string literal (see the translation phases
in 5.1.1.2); thus, an expansion that results in two
string literals is an invalid directive.
6.10.2 Language 6.10.2
166 Committee Draft -- August 3, 1998 WG14/N843
This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 12:54:13 PST