| Add Proposal | Add Analysis | Edit Class, Environment, or Release |
| Number | 307
|
| Category | errata
|
| Synopsis | 27.19 what happenes with escaped identifiers
|
| State | open
|
| Class | errata-ptf
|
| Arrival-Date | Mar 21 2003
|
| Originator | Stephen Williams <steve@icarus.com>
|
| Release | 2001b
|
| Environment |
|
| Description |
Section 27.19 does not discuss what to do with: - strings containing names which should be escaped, but are not. - strings containing names which do not need to be escaped, but are. In addition, there is no explanation anywhere about what is returned when an application asks for the name of an identifier. When should names be escaped? |
| Fix |
Add a paragraph to section 27.19, something like this: The name argument shall be interpeted the same way that names are interpeted within the HDL. Identifiers which need to be escaped must be escaped in the string pointed to by name. Identifiers which do not need to be escaped can be escaped without any effect. Add a section 26.3.5: 26.3.5 Object name properties The properties vpiName, vpiFullName and vpiDefName return the names of identifiers from the HDL. These names will be escaped only when it is necessary to escape them, regardless of how they are specified within the HDL. |
| Audit-Trail |
From: Stephen Williams <steve@icarus.com> To: chas@cadence.com Cc: ptf-bugs@boyd.com Subject: Re: pending/307: 27.19 what happenes with escaped identifiers Date: Mon, 24 Mar 2003 14:44:25 -0800 > - strings containing names which should be escaped, but > are not. > - strings containing names which do not need to be > escaped, but are. Hmm, the vpiName property of an object returns a string that is the non-hierarchical name of the object. In principle, there is no need at all for that name to include escape characters. For example: wire \foo.bar ; vpi_get_str(vpiName, obj) --> "foo.bar" There is nothing ambiguous in that, the string "foo.bar" is the name of the object, no confusion. I propose that vpiName not ever include the escape characters, they are a part of the data entry details, and not part of the name itself. The C programmer need not guess or cope with the escape sequences, because the string is not otherwise structured. Things get decidedly more icky with vpiFullName. In this case, the simulator should indeed add the escape characters because the C code is expected to possibly parse the hierarchical name. The C code in this case may need to know that a '.' in the string has been escaped. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." From: Shalom Bresticker <Shalom.Bresticker@motorola.com> To: ptf-bugs@boyd.com Cc: Subject: errata/307: 27.19 what happenes with escaped identifiers Date: Tue, 15 Apr 2003 12:31:11 +0300 This is a multi-part message in MIME format. --------------C304A6C35FF78BACC3D93AF7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael.Rohleder@motorola.com wrote: > Thanks. As a matter of fact, my wishlist would be to have two functions, one > providing the name without escaped identifiers, a second where escaped > identifiers are preserved. --------------C304A6C35FF78BACC3D93AF7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from zuk14exr01.mot.com ([10.128.132.48]) by zil05exm01.sps.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id 1R9B72YR; Tue, 15 Apr 2003 11:10:21 +0300 Received: from zwg18exm01.corp.mot.com (zwg18exm01.sps.mot.com [10.170.73.30]) by zuk14exr01.mot.com (Motorola/8.11.6) with ESMTP id h3FEKjV03218 for <Shalom.Bresticker@motorola.com>; Tue, 15 Apr 2003 09:20:45 -0500 Received: from motorola.com (10.170.70.169 [10.170.70.169]) by zwg18exm01.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id W97YSNWH; Tue, 15 Apr 2003 10:10:15 +0200 Message-ID: <3E9BBE5F.BEB2B9B5@motorola.com> Date: Tue, 15 Apr 2003 10:10:07 +0200 From: Michael Rohleder<Michael.Rohleder@motorola.com> Reply-To: Michael.Rohleder@motorola.com Organization: Motorola Semiconductor Products Sector X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Shalom Bresticker<Shalom.Bresticker@motorola.com> Subject: Re: [Fwd: ISSUE 307] References: <3E9BA740.1686E026@motorola.com> Content-Type: multipart/mixed; boundary="------------0E59DA1EAAED64A88DF7D5E2" This is a multi-part message in MIME format. --------------0E59DA1EAAED64A88DF7D5E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks, as a matter of fact, my wishlist would be to have two functions, one providing the name without escaped identifiers, a second where escaped identifiers are preserved. -Michael Shalom Bresticker wrote: -- 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 _____ Subject: ISSUE 307 Date: Mon, 14 Apr 2003 17:52:23 +0300 From: Shalom Bresticker <Shalom.Bresticker@motorola.com> http://www.boyd.com/1364_btf/report/full_pr/307.html <http://www.boyd.com/1364_btf/report/full_pr/307.html> -- 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 _____ ISSUE 307 Add <http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=propose&pr=307> Proposal Add <http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=analyze&pr=307> Analysis Edit <http://boydtechinc.com/cgi-bin/issueproposal.pl?cmd=changeclass&pr=307> Class, Environment, or Release Number 307 Category errata Synopsis 27.19 what happenes with escaped identifiers State open Class errata-ptf Arrival-Date Mar 21 2003 Originator Stephen Williams <steve@icarus.com> Release 2001b Environment Description Section 27.19 does not discuss what to do with: - strings containing names which should be escaped, but are not. - strings containing names which do not need to be escaped, but are. In addition, there is no explanation anywhere about what is returned when an application asks for the name of an identifier. When should names be escaped? Fix Add a paragraph to section 27.19, something like this: The name argument shall be interpeted the same way that names are interpeted within the HDL. Identifiers which need to be escaped must be escaped in the string pointed to by name. Identifiers which do not need to be escaped can be escaped without any effect. Add a section 26.3.5: 26.3.5 Object name properties The properties vpiName, vpiFullName and vpiDefName return the names of identifiers from the HDL. These names will be escaped only when it is necessary to escape them, regardless of how they are specified within the HDL. Audit-Trail From: Stephen Williams <steve@icarus.com> To: chas@cadence.com Cc: ptf-bugs@boyd.com Subject: Re: pending/307: 27.19 what happenes with escaped identifiers Date: Mon, 24 Mar 2003 14:44:25 -0800 > - strings containing names which should be escaped, but > are not. > - strings containing names which do not need to be > escaped, but are. Hmm, the vpiName property of an object returns a string that is the non-hierarchical name of the object. In principle, there is no need at all for that name to include escape characters. For example: wire \foo.bar ; vpi_get_str(vpiName, obj) --> "foo.bar" There is nothing ambiguous in that, the string "foo.bar" is the name of the object, no confusion. I propose that vpiName not ever include the escape characters, they are a part of the data entry details, and not part of the name itself. The C programmer need not guess or cope with the escape sequences, because the string is not otherwise structured. Things get decidedly more icky with vpiFullName. In this case, the simulator should indeed add the escape characters because the C code is expected to possibly parse the hierarchical name. The C code in this case may need to know that a '.' in the string has been escaped. -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, steve at picturel.com and lines to code before I sleep, http://www.picturel.com <http://www.picturel.com> And lines to code before I sleep." Hosted by Boyd Technology <http://www.boydtechinc.com> -- NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated. ___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com <mailto:Michael.Rohleder@motorola.com> \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \ The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( ) *** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! *** --------------0E59DA1EAAED64A88DF7D5E2 Content-Type: text/x-vcard; charset=us-ascii; name="michael.rohleder.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Michael Rohleder Content-Disposition: attachment; filename="michael.rohleder.vcf" begin:vcard n:Rohleder;Michael tel;fax:++49-89-92103-680 tel;work:++49-89-92103-259 x-mozilla-html:FALSE org:Motorola Semiconductor Products Sector;System Design Methodology version:2.1 email;internet:Michael.Rohleder@motorola.com title:Software Technologist adr;quoted-printable:;;Motorola=0D=0ASemiconductor Products Sector=0D=0ASchatzbogen 7=0D=0AD-81829 Muenchen=0D=0A =0D=0A;Munich;;D-81829;Germany fn:Michael Rohleder end:vcard --------------0E59DA1EAAED64A88DF7D5E2-- --------------C304A6C35FF78BACC3D93AF7-- |
| Unformatted |
|
Hosted by Boyd Technology