[fpc-pascal] ReAllocMem problem (?)

Micha Nelissen micha at neli.hopto.org
Sat Mar 12 22:15:18 CET 2005

On Sat, 12 Mar 2005 21:46:15 +0100
mm <mm10 at ellipsa.net> wrote:

> Micha Nelissen wrote:
> >The problem with your approach is: how do you know whether the memory
> >was extended, or left alone because there was no memory available to
> >extend it ? In general, shortage of memory produces a runtime error,
> >but this is configurable by a global var.
> >
> No, that's easy. If the returned pointer is nil, it signals
> the problem. But returning a nil pointer doesn't mean losing
> the pointed memory area. We can save the pointer value before
> calling ReAllocMem (in such situation, Delphi 5 returns a nil
> pointer but the memory area is not lost).

Ah I see, you are right. The documentation does not explicitly say that returning a nil pointer means the memory area has been freed. So both choices are possible within documentation.

In this case I would advise not to free the pointer and explicitly document this choice in the freepascal documentation. (As the user can free the area himself anyways, but can not bring it back). What do the other fpc developers think?

> >Not zeroing it would trigger a bug in the compiler, so I left it in.
> >(Can not remember precisely, but the context was an array of pointers
> >that is realloc'ed, needing the new entries to be zero/nil).
> >
> It would have been preferable to try to fix this particular bug
> otherwise. The fact that the blocks of memory are set to 0 is
> a big waste of time. In the big integer library [*] I am adapting
> to Free Pascal (and not only big integers, but also big
> polynomials over GF(2), big real/complex floats), the routines make
> lots of memory 'reallocations'.

Maybe it would help you more to allocate more space in advance? Or use a data structure not requiring reallocations ? Just some suggestions...
I think it's the same as with classes that are automatically zeroed when creating, but those aren't so big usually... Probably the bugs in the compiler can be found and fixed easily, but also this choice I leave to the core developers. Also seen the fact that delphi does not zero it also, can argue for us not doing it either...


More information about the fpc-pascal mailing list