[Glass] How can I release a malloced CByteArray ....

I've created a ByteArray in "non-Smalltalk" memory via

 "CByteArray malloc: 100"

Now the question: how can I release it again by Gemstone ?

Marten

--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

The short answer is “you can’t!” As indicated in the method comment, this is intended to be used to pass to C functions that take responsibility for freeing the memory. In most cases you should use CByteArray class>>#'gcMalloc:’ so that the external memory is freed automatically when the object is no longer referenced within Smalltalk.

James

On Feb 26, 2014, at 8:03 AM, [hidden email] wrote:

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Hmmm,

I thought that if I talk to an external library it is very good
programming practice that each component is responsible for allocating
and freeing their memory. This is very true, if both systems are working
with different memory allocation libraries.

That means, if I give a malloced memory to an external library the
external library should not free "my" memory.

Marten


Am 26.02.2014 17:12, schrieb James Foster:
> The short answer is “you can’t!” As indicated in the method comment, this is intended to be used to pass to C functions that take responsibility for freeing the memory. In most cases you should use CByteArray class>>#'gcMalloc:’ so that the external memory is freed automatically when the object is no longer referenced within Smalltalk.
>



--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

I’ll let you take that up with the authors of the external library. In the off chance that you are faced with a situation where the authors do not accept your suggestion to rewrite their library, you can still use it.

James

On Feb 26, 2014, at 8:28 AM, [hidden email] wrote:

_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

https://www.securecoding.cert.org/confluence/display/seccode/POS34-C.+Do+not+call+putenv()+with+a+pointer+to+an+automatic+variable+as+the+argument
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

On 02/26/2014 09:16 AM, James Foster wrote:
> "The POSIX function |putenv()| is used to set environment variable
> values. The |putenv()| function does not create a copy of the string
> supplied to it as an argument; rather, it inserts a pointer to the
> string into the environment array.” In this situation the caller
> typically does a malloc() without a free().
>
> https://www.securecoding.cert.org/confluence/display/seccode/POS34-C.+Do+not+call+putenv()+with+a+pointer+to+an+automatic+variable+as+the+argument

So in GemStone, one should use #gcMalloc: if there is any chance that
the memory should be freed before the process exits.

But Marten has a point in that it is usually considered bad practice for
memory to be allocated by one component and freed by another. In the
putenv() example, it may well be that free() is never called by anyone,
if the putenv() call succeeds and the environment variable is used until
the process exits.

But there are cases where the memory used by putenv() *should* be freed,
and if so the component that malloced the memory should be the one to
free it. On case is shown in the code example on the cert.org page that
James references. If putenv() does not succeed, free() is called.
Another case is that if putenv() was called again with a different
string for the same variable, the previous string should be freed, or it
would be considered a memory leak.

Regards,

-Martin
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass

Ok,

then the other way around: then it is ok to assume that an external
library can follow the same way:  that it allocates a memory block,
gives it via a return parameter back to GemStone and tells me to release
the memory if i do not need it any more.

This is also not possible - a simple free-call binding is missing .....


--
Marten Feldtmann
_______________________________________________
Glass mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/glass