RE: [sv-cc] Multiple NUL Terminated Strings (WAS: Clarification on my earlier mail regarding on strings)

OK, I agree with your understanding of the proposal.
Requiring the (possibly additional) terminating NUL
meets all needs.

And you are correct, that is what the proposal as
submitted for #201 states.

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 9:26 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)
]
] 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:57:46 2004