From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_00, GUARANTEED_100_PERCENT autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: "Alejandro R. Mosteo" Newsgroups: comp.lang.ada Subject: Re: Interfaces.C.Strings chars_ptr memory management strategy Date: Thu, 31 May 2018 12:34:23 +0200 Organization: A noiseless patient Spider Message-ID: References: <6ff31dc6-31e7-4755-bda0-1b53fa02f31f@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Thu, 31 May 2018 10:34:23 -0000 (UTC) Injection-Info: h2725194.stratoserver.net; posting-host="d6a9341a58a00c79c2f55652b7e49f19"; logging-data="9138"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kvdiqD/cXMxoxP3nwiM5C" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Cancel-Lock: sha1:oOOVaWhZIYXhJN0/M4eURimr+F8= In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:52803 Date: 2018-05-31T12:34:23+02:00 List-Id: On 30/05/2018 21:56, Randy Brukardt wrote: > "Alejandro R. Mosteo" 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. > >