Subject: RE: DirectC memory ownership - proposed rules
From: Joao Geada (joao@synopsys.com)
Date: Mon Dec 16 2002 - 13:42:14 PST
Michael,
you can return strings in the heap as long as the C code maintains some
reference to those strings so
that it can free them when necessary. Eg:
--- sv ---
extern char *theCfunc(void);
--- c ---
/* generate a string and pass back to SV */
char *theCfunc(void)
{
static char *currStr = NULL;
if (currStr) free(currStr);
currStr = malloc(..);
...
return currStr;
}
As to using const: Yes, I am in favor of:
1- having the SV compiler be responsible for generating a header containing
prototypes of all extern
functions declared within SV.
In this case it would be recommended that user's C code included this
header file, if for no other reason
than to check type and prototype consistency
2- on these automatically generated prototypes:
a) input ports are const. Input arguments passed by value are const,
Input arguments passed by
reference are const pointers to const data
b) inout ports of type string are non-const pointers to const data. User
can change what the pointer is
but not the contents of the string it points to
c) inout ports of all other types are const pointers to non-const data.
User can't change the pointer but
can change the data it points to
However, all the above is a "stylistic" issue and also touches upon use
model issues that we haven't
discussed yet. Functionally you'd get the same behavior if users would
comply to the same const rules
described above.
Joao
============================================================================
==
Joao Geada, PhD Principal Engineer Verif Tech
Group
Synopsys, Inc TEL: (508)
263-8083
344 Simarano Drive, Suite 300, FAX: (508)
263-8069
Marlboro, MA 01752, USA
============================================================================
==
-----Original Message-----
From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
Sent: Monday, December 16, 2002 2:41 PM
To: Joao Geada
Cc: sv-cc
Subject: Re: DirectC memory ownership - proposed rules
Joao,
thanks a lot for this clarification. Please make sure this information
also finds its way into the C Layer definition. Especially the lifetime
statements are essential and exactly what I have requested to define.
Just twos comments on this:
a) Your definitions on the output ports prohibit the usage of the heap for
building the strings. Otherwise the allocated memory would be leaked (or you
need to do some clumsy things), since it must live when terminating the
function and can thus not be freed' by it. Since it is furthermore not
possible to use strings allocated on the stack (for obvious reasons), the
only possible/permitted (C) variables are globals or const strings (or some
tricks with the heap). Not the most elegant solution, but of course working.
b) i: Your definitions of the inout port cries for 'const' [without going
into the whole discussion again] to aid in asserting the read-only
attribute. ii: I would request a 'do' and a 'don't' example for this case,
to make the restriction even more clear.
Thanks again,
-Michael
This archive was generated by hypermail 2b28 : Mon Dec 16 2002 - 13:42:56 PST