Some small points.
1. On the ability to trace where the memory allocation failed, it would be
handy to take advantage of preprocessor variables to provide origin information
relative to the source code.
That might be (using the previous example), with a header file having something
like
01 void* CheckedAlloc(size_t n, char* loc)
02 { void* p = malloc(n);
03 if (p == NULL)
04 AllocFailure(loc);
05 return p;
06 }
10 #define ChkAlloc(n) (CheckedAlloc((n), #__FILE__ ":" #__LINE__ ))
After struggling through whatever it takes for getting standard preprocessor
variables to show up as string literals in the expanded file that is fed to the
compiler's parsing stage. That will likely make this a platform-dependent
header, since preprocessor mileages vary.
2. I think the use of longer names is partly because we lack the ability to
operate with namespaces in Standard C. But there are ways to alleviate some of
that (as in line 10).
3. I would not reflect the specific allocation method in the name of the
wrapper, since it may vary from platform to platform.
- Dennis
-----Original Message-----
From: jan i [mailto:[email protected]]
Sent: Thursday, February 19, 2015 05:03
To: [email protected]
Subject: Re: Checking malloc success and adding perror()
On 19 February 2015 at 13:40, Peter Kelly <[email protected]> wrote:
> > 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)
>
+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
>
+1
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
API.
> 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.
rgds
jan i.
>
> —
> 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)
>
>
