[Opl-dev-development] ALLOC and FREEALLOC problems

[<ktk...@hi...>]

Hello Rick,

I'm not sure if you already know this issue of ALLOC,
LENALLOC and FREEALLOC, so I report here.
There's a person in the following forum posting an
interesting question:
http://www.pdastreet.com/forums/showthread.php?s=ed06f378f1869828167cb7ff92862f63&threadid=21720

His code example has unnecessary bits, so I write the
stripped-down version here:

PROC test:
	LOCAL test&, test2&
	test&=ALLOC(30000000)
	PRINT LENALLOC(test&), "allocated"
	GET
	test2&=ALLOC(10000000)
	PRINT LENALLOC(test2&), "allocated"
	GET
	FREEALLOC(test&)
	PRINT "freed, now test& occupies", LENALLOC(test&)
	GET
	FREEALLOC(test2&)
	PRINT "freed completely, now test& occupies", LENALLOC(test&)
	PRINT "and test2& occupies", LENALLOC (test2&)
	GET
ENDP

I've run this code on my netBook with 64Mb RAM.

One of the two problems is that, after the first FREEALLOC(test&),
the OPLR still holds the large memory area used to store
30000000 bytes (for example you can confirm this by going to the
system screen and check the free memory).
It is only after the second FREEALLOC(test2&) that the memory
for test& is actally released. I don't know if this is a bug
or not, but if this is the correct behavior it's better to 
document it somewhere.

The second problem is that, after the memory area was actually
released, LENALLOC returns some bogus value.
This could be changed in such a way that:
1. The value of test& is changed to -1 or whatever when
   FREEALLOC(test&) actually worked.
2. LENALLOC(buf&) returns zero when the value of buf& is negative.

In principle we can use zero instead of negative value, but
I think it's safer to use negative because zero might actually
be a valid value for OPLR to point to some valid memory area.
 
Would you please confirm if this is also the case with Symbian
OPL?

I wanted to look into this by myself, but as I said in the
previous email I cannot spare much time on OPL at the moment.

Best regards,
Keita