A series of emails on this topic came in from a non-member.
Neil
-------- Original Message --------
Subject: BOUNCE sv-ec@eda.org: Non-member submission from [Slater Rob-R53680 <R.Slater@freescale.com>]
Date: Mon, 22 Nov 2004 23:48:26 -0800 (PST)
From: owner-sv-ec@eda.org
To: sv-ec-approval@eda.org
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
-- --------------------------------------------------------------------- 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 ---------------------------------------------------------------------Received on Tue Nov 23 13:33:26 2004
This archive was generated by hypermail 2.1.8 : Tue Nov 23 2004 - 13:33:36 PST