corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: Checking malloc success and adding perror()
Date Thu, 19 Feb 2015 12:40:42 GMT
> On 19 Feb 2015, at 7:06 pm, Dennis E. Hamilton <> wrote:
> +1 about a cheap check and common abort procedure for starters.
> I think figuring out what to do about cleanup and exception unwinding, and even what
exception handling to use (if any) is a further platform-development issue that could be masked
with simple still-inlineable code, but needs much more architectural thought.

I’m fine with us using wrapper functions for these which do the checks - though please let’s
use xmalloc, xcalloc, xrealloc, and xstrdup instead of DFPlatform* (it’s nothing to do with
platform abstraction, and these names are easier to type). (as a side note we can probably
cut down on prefix usage a lot as long as we don’t export symbols; this was just to avoid
name clashes with other libraries)

In my previous mail I really just wanted to point out that by itself, this doesn’t really
solve anything - the issue is in reality far more complicated than a simple NULL pointer check.

I can think of two ways we could deal with the issue of graceful handling:

1) Allow the application to supply a callback, as Jan suggested

2) Adopt a “memory pool” type strategy where we create an memory pool object at the start
of conversion which tracks all allocations that occur between the beginning and end of a top-level
API call like DFGet, and put setjmp/longjmp-style exception handling in these API calls.

The second approach is in fact already used to a limited extent with the DOM API. Every document
maintains its own memory pool for storing Node objects (and the text values of nodes)… this
is freed when the document’s retainCount drops to zero. I did this because it was much faster
than traversing through the tree and releasing nodes individually (at least in comparison
to have nodes as Objective C objects - the ObjC runtime was undoubtedly part of that overhead).

Dr Peter M. Kelly

PGP key: <>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message