[sv-cc] New version of SV-CC 201 is uploaded

Hello everyone,

I reflected on SV-CC 201 and the issues that were raised
last meeting on the trailing null byte and embedded nulls.

My idea is that we give the C programmer full power and visibility
when working with SystemVerilog string arguments. I don't want
the DPI argument passing mechanism to interpret or modify the
contents of string arguments in any way.

The following explains how string arguments can work:

In simple cases (no embedded nulls), SystemVerilog simulators will
pass string arguments in C representation, ensuring a null byte is
present at the end of the string.

In embedded null cases, SystemVerilog simulators pass string
arguments to C including embedded nulls, also ensuring a null
byte is present at the end of the string.

If a naive C programmer works with such a string, the string will
appear to be shorter than it really is. It will appear to end at
the location of the first embedded null.

There is an easy technique that allows the C programmer full visibility
of the SystemVerilog string, including all embedded nulls and stretches
of the string between the embedded nulls. The technique is simply
for the user to pass the length of the string argument as a separate
int argument to the function. The C programmer's parsing code can then
depend on the known length of the string, rather than scanning until
the first null byte is detected.

The reason I prefer this simple approach over alternatives such as
replacing all embedded nulls with a whitespace ' ', period '.', or
other, is that no loss of information occurs during argument passing.

SV users have to go out of their way to generate strings with
embedded nulls. Embedded nulls don't just happen by accident,
sloppy programming practices, or implementation artifacts.
If users create such strings and want to pass them to DPI import
functions, it could be seen as a bad limitation of the standard
if we didn't let those users "see" and use their strings in the
manner in which they were created.

    http://www.eda.org/svdb/bug_view_page.php?bug_id=0000201

Thanks and Regards,
Doug
Received on Wed Nov 17 00:18:24 2004