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

Another in a series of emails from non-members on this same topic.

Neil

-------- Original Message --------
Subject: BOUNCE sv-ec@eda.org: Non-member submission from ["Steven J. Dovich" <dovich@cadence.com>]
Date: Tue, 23 Nov 2004 07:32:41 -0800 (PST)
From: owner-sv-ec@eda.org
To: sv-ec-approval@eda.org

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

> This is yet another reason why I feel that SystemVerilog should fall in line
> (with C in this case) and say a string is NULL terminated character stream an
> d NOT permit embedded NULLs.
>
> If you want to embed NULLs in a data pull then declare a block of memory and
> pass that around. Strings are not general purpose storage and don't need the
> flexibility of such.
>
>
> Allowing programmers to enbed nulls is just going to cause user headaches whi
> le not adding any usefulness to the language.
>
>
> Rob Slater
> Freescale Semiconductor (FSL)
> r.slater@freescale.com
>
>
> > -----Original Message-----
> > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf
> > Of Warmke, Doug
> > Sent: Monday, November 22, 2004 23:53
> > To: sv-ec@eda.org; SV-CC
> > Subject: [sv-ec] Clarification on my earlier mail regarding on
> > strings
> >
> > Hi Everyone,
> >
> > It was noted that my mail to SV-EC on strings had a technical
> > mistake
> > which could lead to confusion.
> >
> > The mistake is that when I referred to the "strlen()" function,
> > I should
> > have been more explicit. The function I intended to refer to
> > was the
> > the len() function described in SV3.1a LRM Section 3.7.1.
> >
> > Here is Section 3.7.1 in entirety:
> >
> > function int len()
> >
> > - str.len() returns the length of the string, i.e., the
> > number of
> > characters in the string (excluding any terminating
> > character).
> > - If str is "", then str.len() returns 0.
> >
> > The C library function "strlen()" will work predictably on any
> > string
> > passed to DPI from SystemVerilog. The first NULL in the string
> > will
> > serve as the end-of-string sentinel, and the length of the
> > string up
> > to but not including that character will be the return value of
> > C's strlen().
> >
> > If C programmers want to handle strings with embedded NULL's in
> > a robust fashion, they will not be able to make use of standard
> > C string utilities like strlen(). Rather they will have to code
> > their own string handling utilities that have support for
> > embedded
> > NULL bytes. This is in perfect conformance with existing C
> > standards,
> > in which there is no built-in support for embedded NULL's in the
> > std
> > C library.
> >
> > Section 3.7.1 above should probably be enhanced by SV-EC to
> > explicitly mention that each embedded NULL character is counted
> > as one byte in the overall string's length. The description
> > already mentions that the value returned by len() is exclusive
> > of any trailing NULL used by the implementation (i.e., not
> > explicitly embedded by user code).
> >
> > Thanks, and sorry for any confusion my earlier mail caused.
> >
> > Regards,
> > Doug
>

/sjd

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