Re: [sv-cc] Item 526 (vpiValid): issues and concerns

I have a comment about the reallocation of memory for an object.

Whenever an object is resized, reallocated or any other property change
for that matter, the inherent properties of that particular handle are 
going
to change. So I contend it should be safe to say that this handle  is 
not valid
anymore and it needs to be reacuqired by the user.
My view point maybe biased based on implementation specific work that I do
but I believe that vpi applications do rely that all the properties of 
particular
handle are going to hold true for their lifetime.

regards,
Rohit
Duncan, Ralph wrote:

> Item 526 (vpiValid property) raises several non-trivial issues:
>
> 1. Semantics: Reallocation and vpiHandle behavior
>
>      The knowledge that a dynamic variable has had its memory 
> deallocated has little value in
>      itself.  Presumably, the value lies in knowing whether subsequent 
> attempts to obtain
>      a value for this variable, using the current vpiHandle, will 
> yield meaningful results.
>
>      We have dynamic objects that can be 'deallocated' as they are 
> resized or moved about in
>      memory  (strings, dynamic and associative arrays).  To deliver an 
> accurate vpiValid value
>      with confidence we must know whether resizing invalidates the 
> vpiHandle or otherwise
>      prevents using it in VPI calls to get new, accurate variable values.
>
>      Thus, a vpiValid capability needs to specify how 
> reallocation/resizing affects vpiHandles
>      and would affect the value of vpiValid.
>
> 2. Scope (relevant datatypes)
>     The current proposal only addresses "non-static variables of class 
> instance[s] and elements
>      of dynamic arrays."  Doug asked if the capability extends to 
> strings, entire dynamic and
>      associative arrays, and automatic variables.
>
>      A vpiValid capability would need to exhaustively specify which 
> data types it addresses.
>
> 3. Vendor obligation and incompatibilities
>
>     (a) One idea was that vendors who do not want to implement dynamic 
> memory
>      tracking could make vpiValid return FALSE, regardless of 
> deallocation status.
>     (b) Although the original proposal had vpiValid indicate dynamic 
> deallocation or its
>     absence, a new suggestion has vpiValid always report TRUE for 
> static variables.
>
>    If both ideas are accepted we have 4 hypothetical possibilities 
> with vendors implementing checking for
>    (a) neither static nor dynamic variables, (b) static variables 
> only, (c) dynamic only,
>    (d) both static and dynamic.
>
>    IMPACTS: If vendors can return FALSE for a kind of variable (static 
> or dynamic) without
>    regard to its actual disposition, then
>    . The only tool behavioral evidence that a vendor actually 
> implements a check for that
>      kind of variable is a result of vpiValue = TRUE.
>    . 'Incompatible' (different) behavior across vendors will always be 
> possible.
>
>    We need to decide whether vpiValid would be relevant to static 
> variables and whether vendors can
>    choose any of the 4 scenarios above.
>
> SUMMARY:
> This is an attractive capability.  Before adding it, however, we 
> should address resizing issues,
> fully delineate which datatypes are relevant for it and consider 
> vendor freedom and obligation to
> implement this.  These matters seem too significant to be decided or 
> specified solely in a note to
> the diagrams.
>
>  
>