RE: [sv-bc] `include

Hello all,

I think we should make "filename" and <filename> quoting
work as much as possible like C.  Embedded are some comments
that can guide the wording towards that goal.

<snip>

   — 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.

DOUG: In C, for "filename" style quotes, the compiler searches
in its implementation-specific include directories in addition
to $cwd and user-specified locations (-I).

   — 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.

DOUG: In C, for <filename> style quotes, $cwd is not searched
by default.  But, if -I/path/to/dir is present, it will be
searched in addition to implementation-dependent locations.

In  addition, note that if -I is present on the cc command line,
it is searched before the implementation-dependent locations
for both <> and "" style quotes.


(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)?

DOUG: I don't know the answer to this, but I think we should leave
the specification vague enough that implementations can have however
many "implementation-dependent locations" they want.

Regards,
Doug

-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.



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