using malloc and brk: something to watch out for

[John P. Linderman]

Chris Torek notes:
> The `moral' in the quoted article does, with some changes, apply to
> any code that is to be called `portable': mix not malloc() and brk(),
> lest ye someday sorrow.

The immediate corollary is ``Thou shalt not use brk()'', because there
in no way to avoid malloc(), at least if you use that paragon of
portability, the standard i/o package.  With 4.3 and ULTRIX, not only
i/o buffers but the FILE structures themselves are acquired with
malloc.  You can supply your own buffers, but I know of no way to avoid
the malloc for the FILE structures.

But if I can't use brk(), and I have an application that uses a LOT of
memory for a short time, then much less memory for a very long time
(sort, as always, comes to mind), then my implementation will hog
memory and perform poorly on those machines that aren't paged.
Programs don't port just because they compile and run, they have to
perform respectably.  In a very real sense, an application may be less
portable if it is denied the use of brk().

If this were just a problem with sorts and brk, I wouldn't worry much.
The more important, underlying issue, is ``Why should the use of brk
result in reduced portability?''.  I'll accept a response like ``Malloc
is a more general paradigm,'' (and I'll put #ifdef's in my code so it
doesn't rely on the existence of brk).  But I am troubled by responses
like ``Some implementations of malloc fail if brk is invoked outside of
malloc.'' As far as I'm concerned, such an implementation is broken.
There's no hope of writing programs that port to broken systems.  You
can add a lot of complexity to your code, and thereby make it less
likely to work on systems that aren't broken, but you can never
anticipate all the ways a library routine might misbehave.  And if you
are not careful, you can ``enshrine'' bugs in such a way that your
code will break if the bugs are fixed.

Of course, ``broken'' and ``portable'' are squishy terms.  For the most
part, I am quite happy if my programs work on BSD, System V, and ULTRIX
distributions, and, for that reason, I will accommodate ``features''
of these systems that I would regard as ``bugs'' in less widely used
systems.  But, at some point, I have to decide that my programs are
``portable enough'', and not worry about the implications of different
implementations, broken or otherwise.

John P. Linderman  Department of Ported Sorts  allegra!jpl