[sv-ec] 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! ***