Re: [sv-bc] `include

The wording seems a little disjointed, in terms of what applies
to relative paths and what to absolute.  I'd suggest:


The syntax permits the filename to be enclosed in either quotes
or angle brackets.  However, when the filename is an absolute path,
only the double quote form of the `include can be used, and only
the specified file is included; the tool will not search
alternate locations.

If the filename is a relative path (or a simple filename with no
path), the syntax determines how a tool searches for the file.

   — When the filename is enclosed in double quotes
   ("filename"), the tool searches in the compiler’s current
   working directory, and optionally a in user specified location.

   — When the filename is enclosed in angle brackets (<filename>),
   then only an implementation-dependent location containing files
   defined by the language standard is searched (see Annex H).
   Relative path names are interpreted relative to that location.

(then continue with your text "A file included ...")

BTW: for <filename>, is it a single implementation-dependent
location, or might it be two (/usr/include and /usr/include/sys)?

-Geoffrey




Bresticker, Shalom wrote:
> That looks ok.
> I suggest a comma after "for a relative path", and "(See Annex H)" after 
> "files defined by the language standard".
>  
> Thanks,
> Shalom
> 
>     ------------------------------------------------------------------------
>     *From:* Gran, Alex [mailto:alex_gran@mentor.com]
>     *Sent:* Monday, March 03, 2008 9:55 PM
>     *To:* Maidment, Matthew R
>     *Cc:* sv-bc; Bresticker, Shalom
>     *Subject:* RE: [sv-bc] `include
> 
>     Matt,
>        I've uploaded a new version of this Mantis proposal last night
>      
>        Here is how the modified text will read
>      
> 
>                 The /filename /can be enclosed in either quotes or angle
>     brackets, which affects how a tool searches for the file.
> 
>     — When the /filename /is enclosed in double quotes
>     ("/filename/"), for a relative path the compiler’s current working
>     directory, and optionally a user specified location is searched.
> 
>     — When the /filename /is enclosed in angle brackets
>     (</filename/>), then only an implementation-dependent location
>     containing files defined by the language standard is searched. 
>      Relative path names are interpreted relative to that location.
> 
>      
> 
>     When the /filename /is an absolute path, only that /filename /is
>     included and only the double quote form of the
> 
>     `include can be used.
> 
>     A file included in the source using the `include compiler directive
>     may contain other `include compiler
> 
>     directives. The number of nesting levels for include files shall be
>     finite. Implementations may limit the maximum
> 
>     number of levels to which include files can be nested, but the limit
>     shall be at least 15.
> 
>     Examples of `include compiler directives are as follows:
> 
>     `include "parts/count.v"
> 
>     `include "fileB" // including fileB
> 
>     `include <List.vh>
> 
> 
>     ------------------------------------------------------------------------
>     *From:* owner-sv-bc@server.eda.org
>     [mailto:owner-sv-bc@server.eda.org] *On Behalf Of *Bresticker, Shalom
>     *Sent:* Tuesday, February 12, 2008 11:35 PM
>     *To:* Gran, Alex
>     *Cc:* sv-bc
>     *Subject:* RE: [sv-bc] `include
> 
>     Alex,
>      
>     On items 3 and 8: `include using double-quote form checks working
>     directory, and any other paths specified by user, typically via
>     +incdir switch on command line. The <> form ignores the
>     user-specified paths (+incdir).
>      
>     "files defined by the language standard" refers, to the best of my
>     understanding, to the List.vh package file defined in Annex H. H.3 says,
> 
>     "To declare a specific list, users must first include the generic
>     List class declaration from the standard include area and then
>     declare the specialized list type:
> 
>     ‘include <List.vh>
> 
>     ...
> 
>     List#(T) dl; // dl is a List of 'T' elements"
> 
>     I think the LRM is ambiguous whether the file name must be List.vh,
>     but let's ignore that. So I would like "files defined by the
>     language standard" to be followed by "(See Annex H)".
> 
>     The LRM implies that this special directory where List.vh is found
>     is not automatically searched by the "" form.
> 
>     Regarding item 5, I guess you can consider a filename to be a
>     special case of a relative path.
> 
>     Regards,
> 
>     Shalom
> 
> 
>         ------------------------------------------------------------------------
>         *From:* Gran, Alex [mailto:alex_gran@mentor.com]
>         *Sent:* Tuesday, February 12, 2008 6:53 PM
>         *To:* Bresticker, Shalom
>         *Cc:* sv-bc
>         *Subject:* RE: [sv-bc] `include
> 
>         Shalom,
>            I am uploading a 2nd version of the proposal after taking
>         your feedback into account,
> 
>         ------------------------------------------------------------------------
>         *From:* Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
>         *Sent:* Wednesday, February 06, 2008 2:45 AM
>         *To:* Gran, Alex
>         *Cc:* sv-bc
>         *Subject:* RE: [sv-bc] `include
> 
>         Alex,
>          
>         Your proposal reads as follows:
>          
>         The /filename /can be enclosed in either quotes or angle
>         brackets, which affects how a tool searches for the file.
> 
>         — When the /filename /is enclosed in double quotes
>         ("/filename/"), for relative a path the compiler’s current
>         working directory, and optionally an implementation-dependent
>         search-path specified by the user is searched.
> 
>         — When the /filename /is enclosed in angle brackets
>         (</filename/>), then only an implementation-dependent location
>         is searched.   Relative path names given inside the angle
>         brackets are interpreted relative to the
>         implementation-dependent location in all cases.
> 
>         1. Regarding "vendor-defined" vs. "implementation-dependent",
>         although "vendor-defined" may not appear elsewhere, "vendor"
>         does and in various combinations, such as "vendor-supplied". I'm
>         not sure it matters.
>          
>         2. There is a grammar error, "for relative a path". Did you
>         mean, "for a relative path"?
>          
>         [AG]  Yes, thanks for catching that, it was a typo.  I was going
>         back and forth between singular 'path' and plural 'paths' and
>         put the 'a' in the wrong place.
>          
>         3. For the double-quote form, I don't think
>         "implementation-dependent" and "specified by the user" go together.
>          
>         [AG] I've made both the double quote and angle bracket form use
>         the phrase "optionally an implementation-dependent location
>         containing files defined by the language standard
>          
>         4. "search path" + "is searched" = redundancy.
>         [AG] yeah, noticed that, but was trying to keep the text for
>         both forms structured the same.  The redundancy is no longer
>         there in my new proposal
>          
>         5. For the double-quote form, it omits the case where the
>         filename is just a name and not a path. 
>         [AG] Isn't a file name just a path with an implicit ./ ?
>          
>          
>         6. This omits the information that the "files defined by the
>         language standard" are to be in the implementation-dependent
>         location.
>         [AG]  I wasn't really sure what value that phrase was adding,
>         but it is no longer removed
>          
>         7. The last sentence could be simplified to "Relative path names
>         are interpreted relative to that location."
>          
>          
>         8. The LRM should clarify explicitly whether the
>         implementation-dependent location is searched for the
>         double-quote form. The LRM implies it is not, but it should be
>         explicit.
>         [AG]  So your believe the LRM should say that
>             double quote form; search *only* current working directory and
>             angle bracket form; search *only* implementation-dependent
>         location?
>          
>             Is that what implementations are doing currently?
>          
>         Regards,
>         Shalom
> 
>         ---------------------------------------------------------------------
>         Intel Israel (74) Limited
> 
>         This e-mail and any attachments may contain confidential material for
>         the sole use of the intended recipient(s). Any review or distribution
>         by others is strictly prohibited. If you are not the intended
>         recipient, please contact the sender and delete all copies.
> 
>     ---------------------------------------------------------------------
>     Intel Israel (74) Limited
> 
>     This e-mail and any attachments may contain confidential material for
>     the sole use of the intended recipient(s). Any review or distribution
>     by others is strictly prohibited. If you are not the intended
>     recipient, please contact the sender and delete all copies.
> 
> 
>     -- 
>     This message has been scanned for viruses and
>     dangerous content by *MailScanner* <http://www.mailscanner.info/>,
>     and is
>     believed to be clean. 
> 
> ---------------------------------------------------------------------
> Intel Israel (74) Limited
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.