this is also a fairly simple question that should be easy
to resolve.  How is the implementation supposed to manage the
memory for strings returned as a result of a parameter file
lookup of a string-valued parameter?  The simple approach would
be to return a const char * to the internal database
representation of the string.  But that pointer would most
likely be invalid after an OverrideAttributeStringValue() of
the attribute.  The problem is, the life time of the
const char * returned by AttributeStringValue() is not
specified.  Hence, I must assume the life time is till the
end of time a.k.a. eternity or, more mundane, the end of the
program :-)

It follows that the application internally must create copies
of the string values and pass pointers to the copies.  It must
keep track of the memory allocated and given the memory allocation
semantics it must also take responsibility for deallocating the
memory.  However, the only point where that can happen is at
Shutdown() time.  This means the API has a builtin memory leak
if my line of reasoning is correct.

The question is simple, the answer affects implementation, and
I think it would be nice to clarify in the spec how the
implemenation is supposed to handle string values.  I see two
possibilities:

  1) The implementation shall return a copy to the string value ...

  2) The implementation returns a pointer to the string value [...]
     The implementation guarantees the pointer is valid until
     Shutdown() is called for read-only attributes.  For
     non-read-only attributes, the implementation guarantees the
     pointer is valid until Shutdown() or
     OverrideAttributeStringValue() of the attribute.

>>Hi John, 


>>> I like proposal 2) below. It keeps things simple. 

>>I came to the same conclusion. The only complication is that in 
>>a multi-threaded environment the string value pointer could be 
>>invalidated by another thread at any time. In a non-preemptively 
>>scheduled threading system the workaround is to copy the string, 
>>but what about a preemptively scheduled threading system? In 
>>such a system a thread switch could happen between getting the 
>>string attribute and copying it. Are preemptively scheduled 
>>threading systems (e.g., pthreads) outside the scope of SCE-MI? 

>>> > 2) The implementation returns a pointer to the string value [...] 
>>> > The implementation guarantees the pointer is valid until 
>>> > Shutdown() is called for read-only attributes. For 
>>> > non-read-only attributes, the implementation guarantees the 
>>> > pointer is valid until Shutdown() or 
>>> > OverrideAttributeStringValue() of the attribute. 

>>I meant to add the phrases `whichever comes first' at the end of 
>>this paragraph. 

>>Per

If (2) is spelled out, I think it would be an acceptable behavior.
It would certainly be easier for the implementation and would not
suffer from the builtin memory leak.  To make it even more user
friendly we could add a note like this:

  NOTE--If the application needs the string value for an extended
  period of time, it may copy the string value to a privately
  managed memory area.

Note, this only affects implementation defined attributes, as
the attributes defined by SCE-MI are all read-only.  Still, the
issue exists.

Per

-- johnS I like proposal 2) below. It keeps things simple.