Per,
I like proposal 2) below. It keeps things simple.
-- johnS
Bojsen, Per wrote:
> Hi,
>
> 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.
>
> 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
>
-- This email may contain material that is confidential, privileged and/or attorney work product for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission /\ is strictly prohibited. If you are /\ | \ not the intended recipient please | \ / | contact the sender and delete / \ \ all copies. /\_/ K2 \_ \_ ______________________________/\/ \ \ John Stickley \ \ \ Principal Engineer \ \________________ Mentor Graphics - MED \_ 17 E. Cedar Place \ john_stickley@mentor.com Ramsey, NJ 07446 \ Phone: (201) 818-2585 ________________________________________________________________Received on Wed Mar 24 19:11:24 2004
This archive was generated by hypermail 2.1.8 : Wed Mar 24 2004 - 19:11:26 PST