Re: [sv-cc] RE: [sv-ec] Clarification on my earlier mail regarding on strings

More email from the same series of emails.

Neil

-------- Original Message --------
Subject: BOUNCE sv-ec@eda.org: Non-member submission from ["Jim Vellenga" <vellenga@cadence.com>]
Date: Tue, 23 Nov 2004 12:20:28 -0800 (PST)
From: owner-sv-ec@eda.org
To: sv-ec-approval@eda.org

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
]
]

-- 
---------------------------------------------------------------------
Neil Korpusik                                     Tel: 408-720-4852
Member of Technical Staff                         Fax: 408-720-4850
Frontend Technologies - ASICs & Processors (FTAP)
Sun Microsystems
email: neil.korpusik@sun.com
---------------------------------------------------------------------