From: "Alejandro R. Mosteo" <alejandro@mosteo.com>
Subject: Re: Interfaces.C.Strings chars_ptr memory management strategy
Date: Thu, 31 May 2018 12:34:23 +0200
Date: 2018-05-31T12:34:23+02:00 [thread overview]
Message-ID: <peoj3f$8ti$1@dont-email.me> (raw)
In-Reply-To: <pemvls$26v$1@franka.jacob-sparre.dk>
On 30/05/2018 21:56, Randy Brukardt wrote:
> "Alejandro R. Mosteo" <alejandro@mosteo.com> wrote in message
> news:pem7s0$go4$1@dont-email.me...
>> On 26/05/2018 00:22, NiGHTS wrote:
>>> I am creating a binding to a C library that requires me to repeat the
>>> same function but with a string parameter that changes on each call. I
>>> don't want to have to keep creating and destroying string memory for all
>>> of these function calls. I would like to create the memory for the string
>>> once, allocate enough space so it doesn't need to grow, and reuse that
>>> memory for the function call every time I need to pass a new string to
>>> it.
>>
>> I'm currently using this:
>>
>> https://github.com/mosteo/cstrings
>>
>> which is not what you want since it allocates on every instance (although
>> on the stack). Still, it might give you some ideas.
>>
>> I'm still unsure if that's 100% guaranteed to be safe; for the experts out
>> here, the question is, in a call to a C function like this:
>>
>> Call_To_C_Function
>> (Function_That_Returns_A_Limited_Tagged_Type (...)
>> .Subprogram_That_Returns_A_C_Pointer_To_Data_In_The_Tagged_Type);
>>
>> Is the in-place built limited tagged type guaranteed to live during the
>> call to the C function? (In other words, is the pointer safe (as long as
>> the C side does not make a copy, of course)?
>
> That depends on the master of the parameter. I believe that the master of a
> parameter is that of the call (each call being it's own master for the
> parameters) -- you'd have to look in 7.6.1 to be sure. So they stay around
> as long as the call.
Might that be 6.4.1? 7 deals with packages (in 2012).
Although it was too dense for me anyway :(
> If that wasn't true, passing an aggregate could have the temporary object
> freed/finalized before the call ended, which would be a disaster.
>
>> My suspicion is that once the subprogram returns the pointer, the limited
>> type can be optimized away before the call to the C side. It's not what
>> I'm seeing now, but I don't want to depend on an erroneous assumption.
>
> Don't think this is a problem in general -- and the result of a function
> does *not* belong to the master of the call but rather the enclosing one
> (else you couldn't use it before it went away). You might be able to get it
> with nested calls:
>
> Foo (Bar (Ugh (...))
>
> The result of Ugh is finalized when the call to Bar ends, so if it is
> somehow in the result of Bar, you could get trouble in Foo. You can avoid
> that by declaring the parameter "aliased" (those belong to the *result* of
> the function, so they stick around longer).
The parameter is actually aliased already. So I hope your impressions are
right and I'm on firm ground then, a pleasant surprise.
Thanks,
Alex.
>
> Randy.
>
>
next prev parent reply other threads:[~2018-05-31 10:34 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-25 22:22 Interfaces.C.Strings chars_ptr memory management strategy NiGHTS
2018-05-26 2:52 ` Shark8
2018-05-26 12:44 ` NiGHTS
2018-05-26 13:56 ` Shark8
2018-05-30 13:10 ` Alejandro R. Mosteo
2018-05-30 19:56 ` Randy Brukardt
2018-05-31 10:34 ` Alejandro R. Mosteo [this message]
2018-05-31 22:25 ` Randy Brukardt
2018-06-05 12:42 ` Alejandro R. Mosteo
2018-06-03 18:31 ` ytomino
2018-06-03 19:33 ` Dmitry A. Kazakov
2018-06-03 20:03 ` ytomino
2018-06-04 7:06 ` Dmitry A. Kazakov
2018-06-04 7:47 ` ytomino
2018-06-03 20:37 ` ytomino
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox