[ibis-macro] Re: Draft1 of BIRD147.4 - RE: File naming BIRD Draft 4.

  • From: "Bob Miller" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "bob.miller" for DMARC)
  • To: Bob Ross <bob@xxxxxxxxxxxxxxxxx>
  • Date: Fri, 11 Nov 2016 09:47:54 -0700

Comments on BobR's questions:

----



In BIRD147.4, what is the “absolute” path versus relative path in this
statement?



The contents of the “path string” concatenated into BCI_ID can either be an
absolute path, or a path relative to the current working directory of the
process running the executable model.



The File naming BIRD states:



Absolute files names (e.g. that begin with // or C:) are not permitted.


I think the statement in 147.4 can be deleted.  This makes the EDA tool's
choice of BCI_ID more restrictive, but if the EDA vendors are OK with it, I
as a model maker don't care.



----



In the File naming BIRD there is a statement:



A “file name” may also be a directory.



In general this should not true and would lead to ambiguity regarding which
file in the directory to use.



The only place I know that this is relevant and  legal is under the
parameter Supporting_Files where some of the “file names” can be
directories.



Perhaps we need to look at the general statement closer.


Agreed. This is consistent with my earlier comment about the use of "file
names" in places where the broad definition of "file name"  as proposed is
not appropriate for the specific use context.

----



The example shows in the file name ID the sequence: “ ..”



(BCI_ID (Usage In) (Type String) (Value "../dll_scratch_dir/channel1")



The File Naming BIRD states:



The character sequence “..” is not permitted



The example should be changed, provided everyone can live with the more
restrictive usage. Question: why should ".." be disallowed if the EDA tool
knows that ".." is part of a legal path within it's sphere?


Regards,


Bob



On Thu, Nov 10, 2016 at 5:22 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:

Bob M, etc.



Attached is BIRD147.4, draft2.  Changes are described at the bottom.



Because the file name can include the path, the path discussion (now part
of the file name) seems ok.



Here are some more questions regarding possible contradictions:



----



In BIRD147.4, what is the “absolute” path versus relative path in this
statement?



The contents of the “path string” concatenated into BCI_ID can either be
an absolute path, or a path relative to the current working directory of
the process running the executable model.



The File naming BIRD states:



Absolute files names (e.g. that begin with // or C:) are not permitted.





----



In the File naming BIRD there is a statement:



A “file name” may also be a directory.



In general this should not true and would lead to ambiguity regarding
which file in the directory to use.



The only place I know that this is relevant and  legal is under the
parameter Supporting_Files where some of the “file names” can be
directories.



Perhaps we need to look at the general statement closer.



----



The example shows in the file name ID the sequence: “ ..”



(BCI_ID (Usage In) (Type String) (Value "../dll_scratch_dir/channel1")



The File Naming BIRD states:



The character sequence “..” is not permitted



----



Bob





*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org] *On Behalf Of *Bob Miller (Redacted sender "bob.miller"
for DMARC)
*Sent:* Wednesday, November 9, 2016 9:09 AM
*To:* Bob Ross
*Cc:* Walter Katz; IBIS-ATM
*Subject:* [ibis-macro] Re: Draft1 of BIRD147.4 - RE: File naming BIRD
Draft 4.



Bob, et. al -

"optionally pre-pended with a “path string” in BIRD 147.x now seems
superfluous. (This was originally my language.) It seems like any "file
name" created under Walter's file naming BIRD "section 3" implicitly may
also include the path, which in BIRD147.x is intended.

We could ask whether *all* present and future "file names" will function
as intended with a path. If not, it is likely important to distinguish the
file naming rules for file names which *may* and which *may not* include
a path.

Regards,

Bob Miller

Broadcom, Ltd.



On Tue, Nov 8, 2016 at 3:02 PM, Bob Ross <bob@xxxxxxxxxxxxxxxxx> wrote:

All,



Attached is draft1 of a BIRD147.4 change related to the File naming
proposal.  The change is described at the bottom.



Does the clause “optionally pre-pended with a “path string”.”  apply here
when the expanded file name rules can include a path?



Comments?



Bob



*From:* ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@
freelists.org] *On Behalf Of *Walter Katz
*Sent:* Tuesday, November 8, 2016 12:50 PM
*To:* IBIS-ATM
*Subject:* [ibis-macro] File naming BIRD Draft 4.



Mike,



Please post this on the IBIS-ATM working area.



Walter



Walter Katz

wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156



Other related posts: