CERT C Secure Coding Standard: last call for reviewers

STL does not necessarily use dynamic memory allocation.  It makes use of a pattern called
allocators, which make it very possible to use static memory allocation for all objects,
including the internal objects used by STL containers.  This is used in embedded systems quite
a bit.

There are also variations of the STL and various other libraries that are designed for
embedded systems that avoid dynamic memory allocation.  You should see some of the development
frameworks used for making Gameboy, DS, and PSP games.  Unlike the Java games you see on
phones and such, those games push their respective hardware to the limit and need heavy
control over all memory allocations to get there.

There are certainly many different ways to handle this. Like many things, much of it comes
down to choice of data structures, code flow, etc. You learn to balance these things, and to
program in a way which minimizes the intrusion of error control in the logic.

Of course, many things in C are tedious--compared to so many scripting and so-called "managed"
languages--so "graceful" is relative. But those people who think its too tedious to handle it
shouldn't be using C. There are many other wonderful languages and application environments to
use, and I use them often myself. If someone thinks bailing on malloc() should be S.O.P., then
maybe they ought to use a Web Application paradigm, where operations--and failures--are
inherently isolated by whatever means the web server uses. There's nothing wrong with
leveraging those tools, and those authors' investments. That's what Free Software is all
about. Unfortunately, too often people want to get down and dirty and write "efficient" code
in C, but then complain when they have to manage the chores, too.

Of course, most of this goes for other languages, like Java, C#, Perl, etc when developing
applications of equivalent complexity; but I can't help it if this lackadaisical attitude has
already gripped those spheres. Exceptions and GC only go so far when a programmer is more
interested in doing the fun stuff, and couldn't care less about the tedious chores. People use
software to get things done; they want software writers' to make the _problems_ disappear
(i.e., to be handled automatically, not dropped on the floor). This is a contract which
shouldn't be broken lightly.

In my experience, though, handling malloc() is no different than handling a malformed HTTP
request, or any other exceptional condition that occurs when an application handles external
resources and data. More often than not, where one finds a function that "gracefully" handles
malloc() failure it also handles other errors. malloc() isn't any different than fopen()
failing, or read() failing, etc. No reason to treat it differently; there's no better way to
"fix" a read()--as alluded to by the OP--than malloc(). If a client disconnects abruptly, I
can't introspect his process stack to "fix" the problem. I just clean up and move along. This
is simply the general pattern of error handling, and it always requires releasing any
intermediate resources. (I've written allocator pools and whatnot, but after a few years I
realized it doesn't actually help that much in terms of effort; if anything it's better just
as a performance boost for small string allocations, or for finer-grained memory limits and
accounting. (See libarena)). 

Granted, there are some failures that can't really be handled well, like a stack overrun
(though I've seen ingenious code which goes pretty far). But malloc() returns NULL for a
reason, and its not because the sanest thing to do is merely exit. Its no excuse, however, to
say that, because C is helpless in some respects to memory management, its futile to manage
all memory management.