What's generally the allocation ownership policy with the C language
bindings for the TCI?

For example, tciCreateTestComponent accepts a String and returns a
TriComponentId struct. Who owns the String, and who owns, say, the
memory that id->compName points to? I.e. can tciCreateTestComponent
re-use its compName argument, or does it have to copy it? Who must
deallocate it? Same for the other pointers inside of the component id.

--
Regards,
Mike

I think it's a tool-specific problem. The manual of tools should provide
solutions for you.
xuezhi

2009/4/28 Michael Sperber <This email address is being protected from spambots. You need JavaScript enabled to view it.>

> What's generally the allocation ownership policy with the C language
> bindings for the TCI?
>
> For example, tciCreateTestComponent accepts a String and returns a
> TriComponentId struct. Who owns the String, and who owns, say, the
> memory that id->compName points to? I.e. can tciCreateTestComponent
> re-use its compName argument, or does it have to copy it? Who must
> deallocate it? Same for the other pointers inside of the component id.
>
> --
> Regards,
> Mike
>

xuezhi xing <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> I think it's a tool-specific problem. The manual of tools should provide
> solutions for you.

I don't think so - what good is an interface description if it doesn't
describe the protocol? Moreover, how would I recombine an arbitrary
TTCN-3 compiler with an arbitrary TCI implementation if they don't agree
on the protocol?

--
Regards,
Mike

Hi Mike,

I agree with you that memory management should be resolved in order to
avoid integration problems. Adri

I think your consideration is right.
But i can't find related specification in the standard document. Under this
situation, it has to be tool-specific.
Of course, general principle may offer useful information such as who
allocate it, who release it. But it's not omnipotence, we can't make sure
the tool you used is obey the rule, unless you refer to its manual.

That's one of the most troublesome problems when using TTCN-3's system, i
think.


2009/4/28 Michael Sperber <This email address is being protected from spambots. You need JavaScript enabled to view it.>

> xuezhi xing <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>
> > I think it's a tool-specific problem. The manual of tools should provide
> > solutions for you.
>
> I don't think so - what good is an interface description if it doesn't
> describe the protocol? Moreover, how would I recombine an arbitrary
> TTCN-3 compiler with an arbitrary TCI implementation if they don't agree
> on the protocol?
>
> --
> Regards,
> Mike
>

Thanks for the pointer!

Jesús Domínguez Colino <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> As a general policy, the one who creates memory is responsible to
> delete it, except when the functions return dynamic memory.

I'm not sure I understand: For example, tciCreateTestComponent must
allocate dynamic memory for its result. So, speaking of "who", it's the
TCI that allocates dynamic memory. Unfortunately, the TCI can't know
when to release that dynamic memory - there's no corresponding function
that the TE could call when the object is no longer needed.

(I think the issue may be that it's somewhat easier to talk about these
things in C++ which has destructors; I'm implementing the C bindings,
however.)

--
Regards,
Mike