dispose: bug or feature?

Frank Heckenbach ih8mj at fjf.gnu.de
Thu Dec 13 07:10:44 CET 2007

Scott Moore wrote:

> >> So, again, it is an error (to pass nil to dispose). However, the 
> >> standard leaves it up to the
> >> implementation when and if such errors are detected, so this is a 
> >> "quality" issue:

GPC produces an error in standard modes.

> >> I'll bet a nickel that the dispose nil behavior you saw was designed 
> >> to compensate
> >> for disposals of zero length data.  I had to solve that problem, but 
> >> did it using a key address,
> >> i.e., new() returns a specific, predefined location that is the 
> >> universal zero length pointer.

Not really -- it's more for convenience (not having to check for nil
before each Dispose; we might have let Dispose set to the pointer to
nil afterwards as well if it was reliable; as has been pointed out
in this thread, it's not).

For allocations we rely on the underlying C library's heap management.
On the system I'm currently on (Linux, glibc), it does allocate some
memory (perhaps for internal data) and returns different addresses
on each zero allocation, but AFAICS it's allowed according to the
C standard to return NULL.

So now that you mention it, there may indeed be a bug on systems
whose libc does the latter, with GPC in standard mode, i.e.
New (empty-record-pointer) would return nil, and Dispose (nil)
would yield a spurious error.


Frank Heckenbach, f.heckenbach at fh-soft.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE  D101 CD02 4C9D 0FE0 E5E8

More information about the Gpc mailing list