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 13:53:39 2004
This archive was generated by hypermail 2.1.8 : Mon Nov 22 2004 - 13:53:51 PST