Re: xmalloc string functions
- From: "cr88192" <cr88192@xxxxxxxxxxx>
- Date: Mon, 28 Jan 2008 11:13:50 +1000
"Eric Sosman" <esosman@xxxxxxxxxxxxxxxxxxxx> wrote in message news:VMednX0onuvkPwHanZ2dnUVZ_q-jnZ2d@xxxxxxxxxxxxxx
Malcolm McLean wrote:Here are six functions implemented on top of xmalloc(). No C programmer should have any triouble providing the implemetations, though replace and getquote are non-trivial.
char *dup(const char *str);
char *cat(const char *str1, const char *str2);
char *catandkill(char *str1, const char *str2);
char *tok(const char *str, const char *delims, char **end);
char *midstr(const char *str, int idx, int len);
char *replace(const char *str, const char *pattern, const char *rep);
char *getquote(const char *str, char quote, char escape, char **end);
char *getline(FILE *fp);
All return strings allocated with xmalloc().
dup() is strdup(), and duplicates a string. cat() concatenates two strings. catandkill concatenagtes two strings, and frees the first. It also returns dup(str2) is the first pointer is null. It is designed for building strings in conveneint loops.
tok() is strtok() that takes a string argument instead of using a global. midstr() takes out a central portion of the string. replace() is a find and replace, getquote() retrives the next quoted string, allowing for the quotes themselves to be escaped. You will have to escape non-quote escaped characters manually, of course. getline() will be a familiar friend.
The specifications are too weak to drive implementations.
What does xmalloc() do when unable to allocate memory? Does
replace() replace all occurrences, or just the first, or just
the last, or what? What does getquote() do with unbalanced
quotes? Does getline() keep or discard the '\n', and what does
it do on an I/O error? (See the recent thread on design of line-
input functions to see how divergent people's opinions are on
how this "familiar friend" should behave.)
I've think we've got something quite powerful here, purely because none of these functions can ever return null for out of memory conditions. It massively simplifies string handling.
... and massively complicates error handling. If xmalloc()
can unilaterally terminate the program, the whole suite is
unusable except in toy programs. If there's a fancier framework,
all functions that use the suite or that call other functions
that might use the suite need to be plugged in to the framework.
Design consists of more than writing a few declarations.
I usually use a garbage collector.
if the app runs out of memory (rare, since I usually use primarily static memory-management approaches, but I can be lazy sometimes), the allocator returns NULL.
now, crashing the app is just lazy, but it is possibly justified on the grounds that on modern systems, running out of memory is rare enough that this is justified (actually, it may well be justified to crash the app before this limit, setting some sort of critical upper bound on memory usage, and provoking the dev to reduce the footprint).
however, often NULL works just as well, because, as a general rule accessing memory through a NULL pointer will crash the app anyways (most of the time, address 0 being set to no-access).
this would be, assuming the issue is not handled.
better though, would be an exception handling system, namely, we crash only if the out-of-memory exception goes unhandled. now, this is less nice in C, which lacks a good exception system (nor the language features to really implement one).
that is not to say, however, that a crude one could not be built around setjmp/longjmp (library feature), or could be added, for example, as a compiler syntax extension that rewrites exception handlers into the library feature's form.
thus, in this case, an unhandled exception thus results in an abort (sadly, an actual 'crash' at this point is pointless, since the context of the exception is already lost).
of course, another approach would be threaded or recursive exception handling (in C, however, there would be present other problems, and semantics which would be problematic to reconcile with the unwinding variety).
the system could, likely, be made to handle both, with some handlers set to behave in a recursive manner (more like signal) and others in an unwinding manner (longjmp). for semantic reasons, likely an unwinding handler would silently ignore any previous recursive handlers (them being invoked in an essentially meaningless context).
throw:
if last handler is signal-style, invoke callback;
otherwise, unwind to last handler.
handler:
if correct exception, do handling actions, and resume execution post handler;
if there is another unwinding handler, unwind to that handler;
else, rethrow an unhandled exception.
--
Eric Sosman
esosman@xxxxxxxxxxxxxxxxxxxx
.
- References:
- xmalloc string functions
- From: Malcolm McLean
- Re: xmalloc string functions
- From: Eric Sosman
- xmalloc string functions
- Prev by Date: Re: Thoughts on file organisation
- Next by Date: Re: xmalloc string functions
- Previous by thread: Re: xmalloc string functions
- Next by thread: Re: xmalloc string functions
- Index(es):
Relevant Pages
|
