Re: SCE-MI: String Parameter Values

From: Stickley, John <john_stickley@mentorg.com>
Date: Wed Mar 24 2004 - 19:09:45 PST

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