> On 19 Feb 2015, at 7:06 pm, Dennis E. Hamilton <[email protected]> 
> 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
[email protected]

PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key>
(fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

Reply via email to