OpenEuphoria

1. ? free()

• Posted by Bernie Ryan <xotron at bluefrog.com> Apr 19, 2005
• 463 views
• Last edited Apr 20, 2005

If you have a atom variable that points to
some allocate memory and then you
you use the free() function to free it.

The variable will still contain the address
location even though the memory was deallocated.

I always thought that variable would be set to ZERO.
That is probably why user's are have mysterious crashs.

Would'nt it be more logical for the interpreter to set
it to ZERO when free()is called ?? 

Bernie

My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

3. Re: ? free()

• Posted by Mario Steele <eumario at trilake.net> Apr 20, 2005
• 434 views

Greg Haberek wrote:
> The interpreter knows this as an atom, not a pointer. It is your job
> to set the atom to zero if you require this. Chances are that you're
> using this pointer in a routine somewhere, so it is freed out of
> memory anyway.

Actually, the interpreter doesn't know what the context of the varaible is.
It knows that the variable is atomic, and therefore, it requires that the
value of it, be a numeric value that is within the Atomic range, as defined
in the documentation.

The same applies sequences, and integers.  However, with sequences, it 
basically becomes the point, of it requiring to be a container array, where
any data may be placed in it.  As far as Euphoria is concerned, it doesn't
care what is in it, as long as it's a value that can pass the type check,
and it can return to a expression.  Expression being mathmatical expression,
variable re-assignment, or passing to a routine declared within the scope of
the program instance.

The only thing that actually makes it a memory address, is that it actually
points to memory, that has been allocated by the Euphoria interpreter, or
points to memory that has been allocated within the program's memory space.
This meaning, that C/C++ Functions in a DLL can allocate memory, but it
allocates the memory within the Program's memory space, and the address
returned, is allways valid for that instance of the program.

This is why you can pass memory pointers between programs, cause they are
never the same between two diffrent instances.  And any attempt to read or
write memory outside the memory space of the program itself, will result in
machine level errors.

But when it comes down to it, in the end, Euphoria really has no clue as to
what the relivence of the data being stored in a variable is.  It keeps it's
own stack of memory addresses that it has allocated, for freeing when the
interpreter finishes executing the instructions.  Also note, that C/C++ 
functions that allocate memory, are never seen by the Euphoria Interpreter.
So therefore, has no idea that they are allocated, and does not keep track of
them.

Mario Steele
http://enchantedblade.trilake.net
Attaining World Dominiation, one byte at a time...

5. Re: ? free()

• Posted by Tommy Carlier <tommy.carlier at telenet.be> Apr 20, 2005
• 438 views

Bernie Ryan wrote:
>   Mario the FREE() function  knows the context of the variable
>   that was initially used to allocate the memory;
>   therefore it can set that variable to zero.
>   
>    Vincent your function won't work because it may be a copy
>    of the orginal variable.

The FREE function does not always know the context of the variable:
the value of the variable is passed, not the address. You can call
free and pass it a literal, or a constant, or an expression.

--
The Internet combines the excitement of typing 
with the reliability of anonymous hearsay.

tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com

7. Re: ? free()

• Posted by Tommy Carlier <tommy.carlier at telenet.be> Apr 20, 2005
• 442 views

Bernie Ryan wrote:
> Tommy do you think that this should be OK ?
> }}}
<eucode>
> include machine.e
> 
> atom a
> 
>    a = allocate(10)
>    ? a
>    free(a)
>    ? a
> </eucode>
{{{

> 
> This should not happen it is just going
> to create error prone code.

How do you solve this situation:

atom a, b
a = allocate(10)
b = a
free(b)

Or this one:

constant a = allocate(10)
free(a)

--
The Internet combines the excitement of typing 
with the reliability of anonymous hearsay.

tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com

9. Re: ? free()

• Posted by Greg Haberek <ghaberek at gmail.com> Apr 20, 2005
• 441 views

> }}}
<eucode>
> include machine.e
>=20
> atom a
>=20
>   a = allocate(10)
>   ? a
>   free(a)
>   ? a
> </eucode>
{{{

>
> This should not happen it is just going
> to create error prone code.

How so? If you're the one writing the code, and you're controlling
which memory addresses you're allocating and freeing, then how could
you allow errors to be introduced? Yes, after you free 'a' it still
has the value of the memory address you allocated. But aren't you
going to re-allocate memory later? And what if this is variable 'a' is
in a routine? Euphoria will remove it from memory anyway when the
routine finishes.

Take this small example from doEvents() in Win32Lib.

-- Allocate a message buffer
    msg = w32acquire_mem(0, SIZEOF_MSG)

    if w32Func( xPeekMessage, { msg, hWnd, 0, 0, PM_REMOVE } ) then
        w32Proc( xTranslateMessage, { msg } )
        w32Proc( xDispatchMessage, { msg } )
    end if
    w32release_mem(msg)

After the call to w32release_mem(), 'msg' still holds the address of a
location in memory, but it will never be used again, since the routine
exits. Next time the routine is called, everything starts from scratch
and 'msg' will hold a different value.

~Greg

11. Re: ? free()

• Posted by Robert Craig <rds at RapidEuphoria.com> Apr 20, 2005
• 429 views
• Last edited Apr 21, 2005

Bernie Ryan wrote:
> That is why the interpeter when it sees a FREE() function
> must determine what variable originally allocated the memory
> and set that variable to zero.
> Then if you try to use that variable, or any copies of it,
> the use will cause an error instead of probigate the error
> throught the program.

What you are asking isn't practical, but what you could do
is write "garbage" into a block just before freeing it. That will
make it likely that if you mistakenly continue to use that block,
you will get a crash or misbehavior of some kind.
That's what I do when I compile the interpreter in "DEBUG"
mode. It helps catch certain errors. free() could do it
for you automatically, but it wastes time, so most people wouldn't
like it.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com

13. Re: ? free()

• Posted by "Christian Cuvier" <christian.cuvier at agriculture.gouv.fr> Apr 21, 2005
• 429 views

> Date: Wed, 20 Apr 2005 13:44:50 -0400
> From: Greg Haberek <ghaberek at gmail.com>
> Subject: Re: ? free()
> 
> 
>>> }}}
<eucode>
>>> include machine.e
>>>=20
>>> atom a
>>>=20
>>>   a = allocate(10)
>>>   ? a
>>>   free(a)
>>>   ? a
>>> </eucode>
{{{

>>>=20
>>> This should not happen it is just going
>>> to create error prone code.
> 
> 
> How so? If you're the one writing the code, and you're controlling
> which memory addresses you're allocating and freeing, then how could
> you allow errors to be introduced? Yes, after you free 'a' it still
> has the value of the memory address you allocated. But aren't you
> going to re-allocate memory later? And what if this is variable 'a' is
> in a routine? Euphoria will remove it from memory anyway when the
> routine finishes.
> 
> Take this small example from doEvents() in Win32Lib.
> 
> }}}
<eucode>
>     -- Allocate a message buffer
>     msg = w32acquire_mem(0, SIZEOF_MSG)
> 
>     if w32Func( xPeekMessage, { msg, hWnd, 0, 0, PM_REMOVE } ) then
>         w32Proc( xTranslateMessage, { msg } )
>         w32Proc( xDispatchMessage, { msg } )
>     end if
>     w32release_mem(msg)
> </eucode>
{{{

> 
> After the call to w32release_mem(), 'msg' still holds the address of a
> location in memory, but it will never be used again, since the routine
> exits. Next time the routine is called, everything starts from scratch
> and 'msg' will hold a different value.
> 
> ~Greg
> 

The following suggestion for Eu enhancements would solve this and another
problem.
Some users asked for object() to return 0 on unitialised vars. I scond them.
One step further would be adding a free_var(var_name) routine, whose purpose 
is to flag a variable as unassigned, which means its previous value is 
considered to be nil.
This:

atom a
constant bufsize=128
a=allocate(bufsize)
--some code here
free_var(a)  --or unassign(a), both are fine with me

tells in a less obvious, less safe way than

atom a
constant bufsize=128
a=allocate(bufsize)
--some code here
free(a)
a=0

that a was used temporarily and its value is not of any concern from that 
point on. After all, 0 may be a valid value in some cases.
As the coder tells the interpreter that this var is not going to be read again 
before a later write access, the interpreter may take any cleanup action like 
GC in a more optimized, reliable way, which is a third benefit.

Comments?
CChris