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

From: Slater Rob-R53680 <R.Slater@freescale.com>
Date: Mon Nov 22 2004 - 23:48:18 PST

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 and 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 while 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
Received on Mon Nov 22 23:48:29 2004

This archive was generated by hypermail 2.1.8 : Mon Nov 22 2004 - 23:48:34 PST