Subject: [sv-cc] SV-CC LRM - array of strings
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Apr 15 2003 - 11:01:00 PDT
Team,
We have another problem, I'm afraid, resulting from the changes in SV 3.0 made
by other committees. Do we want to permit arrays of strings?
I was asked the following question by a person doing the review of the document
for SV-CC:
> one comment I have is how I would interface from SV, to a C function whose
> prototype was
> int f (char *argc[], int argv);
>
> as far as I could see in the document, a string (in SV) would become a
> char* (in C)
> but how would I get to *char[], it is almost like an array of strings in SV.
A natural answer seemed to be "an open array of strings", i.e. something like
this (in SV): import "DPI" function int f (string argc[], int argv);
Then I realized that the current semantics of 'string' differs from the
semantics assumed both in DirectC donation and in "17 items proposal".
The type 'string' was originally intended to be very similar to a generic
opaque pointer, with the sole difference that string literals, like "a text",
would be interpreted as C-style char* pointers rather than as ASCII-based
encoding of bit vectors.
Now, after all additions to SV 3.0, string is a class rather than a C -style
pointer. As a consequence, passing 'string' type argument requires that
additional conversion will be performed; either a pointer must be extracted
from a class object (and perhaps the actual string copied), or a new class
instance be created with a copy of a string. Although this may be tolerable
for individual values of type string crossing the interface, it defies
the assumption that there will be no intrinsic overhead.
Consider now an array of strings. Passing such an array would require
pretty expensive translation.
An array of strings will have different representations on both sides
of an interface, hence it takes a translation: for the whole array and for
each of its elements.
A new array would have to be allocated and filled
with pointers to newly allocated objects, be they class instances or copies of
C strings.
Situation is even worse, because memory will have to be dynamically allocated
and hence memory leaks will be very likely.
All those issues were absent with the original proposal (all strings would have
been allocated statically by a compiler).
IMO the solution is to keep a special flavour of a generic pointer ment
for strings as a separate basic type. So there would be two variants of opaque
pointers: 'handle' and 'cstring' (the actual name doesn't matter.)
Actually, what I'm proposing here is a reversion to the original solution.
You see, language definition is not a random collection of constructs, that
could be mixed and matched at will :-)
Note that classes are not supported in DPI, hence 'string' would not be
permitted either. However, a conversion between a single object of class string
and a single value of type 'cstring' would be supported.
Therefore it would be possible to use an actual argument of type string (for
all directions) for the formal argument of type 'cstring'.
An array of 'string' would not match, however, an array of 'cstring'.
Thanks,
Andrzej
This archive was generated by hypermail 2b28 : Tue Apr 15 2003 - 11:02:33 PDT