bounced email....fwd
-----Original Message-----
From: "Jim Vellenga" <vellenga@cadence.com>
To: <michael.rohleder@freescale.com>
Cc: "Slater Rob-R53680" <R.Slater@motorola.com>, <sv-cc@server.eda.org>,
<sv-ec@server.eda.org>, "Steven Dovich" <dovich@cadence.com>,
"Bresticker Shalom-R50386" <Shalom.Bresticker@motorola.com>
X-Received: By mailgate.Cadence.COM as FAA16642 at Wed Nov 24 05:23:29
2004
X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version
0.74a
on server.eda.org
X-Virus-Status: Clean
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by server.eda.org id
iAODXNLT023713
Let's see if my rephrasing captures what you're saying:
(1) It's fine to allow NUL characters in the body of
a string, if that's what the user chooses to do.
(2) When DPI exports a SystemVerilog string, the
exported C string should contain all the characters
(including NUL's) that were in the SystemVerilog
string, but should also have an additional NUL at
the end.
(3) The C code can now apply the strlen function
safely to return the number of characters up to
but not including the first NUL character -- safely
because there is now always at least one NUL character
in the C string or at the end of it.
Is that it?
Regards,
Jim V.
---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
] -----Original Message-----
] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] Behalf Of Michael Rohleder
] Sent: Wednesday, November 24, 2004 5:12 AM
] To: Jim Vellenga
] Cc: Slater Rob-R53680; sv-cc@eda.org; sv-ec@eda.org; Steven
] Dovich; Bresticker Shalom-R50386
] Subject: Re: [sv-cc] Multiple NUL Terminated Strings (WAS:
] Clarification on my earlier mail regarding on strings)
]
] "Semantics aside"
]
] this is a good statement for the one and only reason why I
] believe the
] current proposal is a good one.
]
] We always have to keep in mind that the 'C' semantics of
] having a string
] with a terminating NUL is
] _defining_ some semantics, which are actually "looking" into
] the content
] of the string. On the other
] side, there are a lot of 'string' types (particularly in
] C++), which no
] longer require the NUL char
] to terminate a string. As such, there is no reason to enforce
] a semantic
] that looks into the content
] of a string.
]
] However, we have clearly stated that any string passed between
] SystemVerilog and C _must_ be
] terminated by a NUL character (to make sure strlen can be
] safely used on
] any such string).
] I have no problem with embedding NUL chars in a string, but clearly
] stating the requirement that
] there _is_ one passed at the end of a string is essential for me.
]
] Regards,
] -Michael
]
]
] Jim Vellenga wrote:
]
] >Rob, the problem with "Semantics aside" is that in this case
] semantics
] >is at the heart of the disagreement. Clearly, when you say or hear
] >"string", you think of a sequence of non-NUL characters
] terminated by a
] >NUL character. Most C programmers agree with you. For
] example, when
] >the second edition of Kernighan and Ritchie defines their String
] >Functions, they clearly have this definition in mind.
] >
] >For a lot of the rest of us, however, a string can mean a
] sequence of
] >characters of some length that may or may not contain NUL
] characters.
] >When I cut my teeth on ASCII in the early 1970's -- before the first
] >Kernighan and Ritchie was published -- NUL was just another ASCII
] >character along with DEL and FS and LF, and we had other ways of
] >determining the length of a string.
] >
] >Either definition works as long as it's used consistently.
] >
] >One problem is that (at least to me) the SystemVerilog chapter on
] >strings doesn't really say which it means. It seems like one really
] >can put 0 bytes into a string via an assignment, and the
] definition of
] >some of the string comparisons talk about "embedded null
] bytes." But
] >that could mean that an embedded null byte acts as limit for the
] >characters actually being compared. I just don't know.
] >
] >But what Doug is trying to do, I think, is come up with a mechanism
] >that works with either definition. That way, users like you who see
] >strings as always NUL-terminated can code and treat them that way,
] >while others can handle character sequences with embedded
] NULs just as
] >easily, provided they track the lengths separately.
] >
] >I can accept that you may not like the second mode of
] thinking, but can
] >you agree that it is at least a self-consistent way of looking at
] >character sequences?
] >
] >Regards,
] >Jim V.
] >
] >---------------------------------------------------------
] >James H. Vellenga 978-262-6381
] >Engineering Director (FAX) 978-262-6636
] >Cadence Design Systems, Inc. vellenga@cadence.com
] >270 Billerica Rd
] >Chelmsford, MA 01824-4179
] >"We all work with partial information."
] >----------------------------------------------------------
] >
] >
] >
] >] -----Original Message-----
] >] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] >] Behalf Of Slater Rob-R53680
] >] Sent: Tuesday, November 23, 2004 11:55 AM
] >] To: sv-cc@eda.org; sv-ec@eda.org
] >] Cc: Steven Dovich; Bresticker Shalom-R50386
] >] Subject: [sv-cc] Multiple NUL Terminated Strings (WAS:
] >] Clarification on my earlier mail regarding on strings)
] >]
] >] Semantics aside, I don't understand what more than one NUL in
] >] a string is supposed to mean. The fact that SystemVerilog
] >] allows this is, in my opinion, a bug which should be fixed.
] >] The relevant committee should address this (SV-EC?)
] >]
] >]
] >] Needless to say when SystemVerilog and C communicate, strings
] >] should be considered a single NUL terminated collection of
] >] characters. (SV-CC)
] >]
] >]
] >] If a users want to build a "string" will multiple NUL
] >] terminators, they should:
] >] (a) Use multiple strings
] >] (b) Be slapped if they refuse to do (a) (I vote this be put in
] >] the spec)
] >]
] >] If a user wants to pass along a block of memory which may
] >] have multiple \0 in it, there are ways to do this without
] >] using strings.
] >]
] >]
] >] Rob Slater
] >] Freescale Semiconductor (FSL)
] >] r.slater@freescale.com
] >]
] >]
] >] > -----Original Message-----
] >] > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf
] >] > Of Steven J. Dovich
] >] > Sent: Tuesday, November 23, 2004 17:29
] >] > To: Bresticker Shalom-R50386
] >] > Cc: sv-cc@eda.org; sv-ec@eda.org
] >] > Subject: Re: [sv-cc] RE: [sv-ec] Clarification on my earlier
] >] > mail regarding on strings
] >] >
] >] > Yes, though as I noted, NUL as a character name is not
] >] > acknowledged
] >] > in the C standard. It is a (somewhat) common usage from the
] >] > ASCII
] >] > standard and is replaced in the C standard with "null
] >] > character".
] >] >
] >] > When spelled in lower case, the word "null" is ambiguous and
] >] > must
] >] > be qualified by "character", "pointer", etc. The upper case NULL
] >] > is the standardized spelling for a "null pointer", a constant
] >] > expression evaluating to zero that is used as a pointer.
] >] >
] >] > /sjd
] >] >
] >] >
] >] > > So NULL is a pointer and NUL is a character?
] >] > >
] >] > > Thanks,
] >] > > Shalom
] >] > >
] >] > >
] >] > > On Tue, 23 Nov 2004, Steven J. Dovich wrote:
] >] > >
] >] > > > My apologies to Doug and Rob for using their comments as a
] >] > soapbox
] >] > > > for a pre-existing problem in the Verilog standard.
] >] > Fortunately 1800
] >] > > > does not appear to have imported the problem, but we need to
] >] > be
] >] > > > vigilant that it does not spread. Now for the standards
] >] > rant...
] >] > > >
] >] > > > To be properly consistent with the C language, we also need
] >] > to
] >] > > > recognize that NULL is not a character, it is a pointer. C
] >] > strings
] >] > > > are composed of characters and are terminated by a "null
] >] > character".
] >] > > > Common usage also designates the character valued as '\0' as
] >] > the
] >] > > > NUL character from the ASCII character names (note the three
] >] > letter
] >] > > > spelling).
] >] > > >
] >] > > > Our draft would be improved by not requiring the reader to
] >] > understand
] >] > > > that we didn't exactly mean what we really said.
] >] > > >
] >] > > > /sjd
] >] > >
] >] > > --
] >] > > Shalom Bresticker Shalom.Bresticker
] >] > @freescale.com
] >] > > Design & Verification Methodology Tel: +972
] >] > 9 9522268
] >] > > Freescale Semiconductor Israel, Ltd. Fax: +972
] >] > 9 9522890
] >] > > POB 2208, Herzlia 46120, ISRAEL Cell: +972
] >] > 50 5441478
] >] > >
] >] > > [ ]Freescale Internal Use Only [ ]Freescale Confidential
] >] > Proprietary
] >]
] >]
] >
] >
]
]
] --
]
] NOTE: The content of this message may contain personal views
] which are not neccessarily the views of Freescale,
] unless specifically stated.
]
] ___________________________________________________
] | |
] _ | Michael Rohleder Tel: +49-89-92103-259 | _
] / )| Freescale Semiconductor Fax: +49-89-92103-680 |( \
] / / | Freescale Halbleiter Deutschland GmbH | \ \
] _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_
] (((\ \>|_/ > < \_|</ /)))
] (\\\\ \_/ / mailto:Michael.Rohleder@freescale.com \ \_/ ////)
] \ /_______________________________________________\ /
] \ _/ \_ /
] / / \ \
]
] The information contained in this email has been classified as:
] General Business Information ( )
] Freescale Internal Use Only ( )
] Freescale Confidential Proprietary ( )
]
]
] *** This note may contain Freescale Confidential Proprietary
] or Freescale 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! ***
]
]
]
]
]
Received on Wed Nov 24 08:42:22 2004
This archive was generated by hypermail 2.1.8 : Wed Nov 24 2004 - 08:42:43 PST