corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Checking malloc success and adding perror()
Date Thu, 19 Feb 2015 13:02:58 GMT
On 19 February 2015 at 13:40, Peter Kelly <> wrote:

> > 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)
+1, I take that as a general statement.....I would really like to cut down
on some of the  looooong names like the new zip functions.

Can we agree on, that when we map a function that could be/are in a
standard library we prefix a "x" like xmalloc(), xzipopen() etc.

> 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

For now let us just declare a function pointer which statically point to a
function in DocFormats, and then move that out when we get around to do the

> 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.
I am all in for that....but 1 step at a time, lets first have the central
function, and then do the memory pool.
I would like to discuss this item later in a bit more detail. One option I
have used a lot is to use "semantic malloc/free", meaning the caller
supplied an ID with the malloc request, so we can cleanup all xmalloc with
that ID and leave the rest.

> 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).
When we have the callback that might be easier and cleaner to use.

jan i.

> —
> 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