K
Kelsey Bjarnason
1:
It is not possible to check EVERY malloc result within complex software.
Says who? There are a limited number of places memory is allocated, thus
a limited number of places checks need to be put in.
3:
A solution like the one proposed by Mr McLean (aborting) is not possible
for software quality reasons. The program must decide if it is possible
to just abort() or not.
Oh, this solution is always *possible*, but I'd be very much annoyed with
any developer stupid enough to adopt this as a default strategy in any
application I actually use.
Solution:
1) At program start, allocate a big buffer that is not used elsewhere in
the program.
Note that in at least one app, I do exactly this - and I *expect* that
the allocation will fail on a pretty regular basis. Of course, if I'm
stupid enough to be using something like Malcolm's xmalloc, it's too
late, the app has already bombed by the time I would normally just detect
the NULL and reduce the size of the request.
'Sides, it's a messy approach, one which ties up resources you don't
really need, resources best left alone for other things. Just because it
makes *your* app easier to write doesn't mean it's a good idea - ponder a
word processor grabbing 128MB for document space, with no documents
loaded, on an otherwise busy machine.