Jim Vellenga wrote:
>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.
>
>
>
Yep. DPI should be agnostic to the content of a string. (It also does
not look into a structure to interpret its content, does it ?)
>(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.
>
>
>
Yes. But the phrasing should be "..., but MUST also have an additional
NUL ..."
>(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.
>
>
>
Yes. Any blind C programmer can run strlen on the returned string and
will get a result
that is equal or less than the actual length of the string. It is
guaranteed that the returned
length does not exceed the actual length and cause subsequent problems
(e.g. because
the strlen is part of a strcpy call).
>Is that it?
>
>
>
Yes. We have discussed this in our meeting (and my understanding was
agreed upon this),
but I had the feeling that this important piece has not received the
appropriate attention
of the people.
Thanks for asking,
Best regards,
-Michael
>
>
>] -----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! ***
>]
>]
>]
>]
>]
>
>
--
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 06:26:29 2004
This archive was generated by hypermail 2.1.8 : Wed Nov 24 2004 - 06:26:44 PST