Hi,
Going through previous posts, apparently the memory management is not
something that the standard C defines. I have read various posts and
the word compilers and OS implementations have been used often. My
confusion is what is the line, if any, that divides the two? What part
of it is compiler dependent and which one is OS? Perhaps this is OT
here and more specific to compiler and OS community but I could not
figure out how to ask a general question in a specific "compiler" /
"OS" community. So wanted to gather some basic thoughts here before
asking the question to those forums.
The C library provides the functions malloc(), calloc(),
realloc(), and free() to manage memory. Their behavior is
defined by the C Standard.
Some aspects of that behavior are left to the implementation's
discretion. For example, there are two schools of thought about
what malloc(0) should return: NULL or a pointer to an object of
zero size. The practical effect of such a difference is rather
small, but some operating systems find it "more natural" (for
reasons of their own) to choose one behavior over the other. Now
and then, somebody tries to explain the choice by describing the
characteristics of some particular operating system.
The C Standard specifically allows the two variant behaviors
for malloc(0), but some other variations are more debatable. The
question of "overcommitting memory" is argued here from time to
time, with no little heat. (Search the archives for the arguments;
I don't propose to repeat them.) Roughly speaking, the debaters
fall into two camps: Those whose concern is for the proper behavior
of an individual program, and those who care about the well-being
of the entire system and all the programs it runs. Now and then,
somebody tries to demonstrate that one position is better than the
other by recounting the idiosyncrasies of this or that system.
Your larger question about how to draw a line between the
compiler and the operating system is tougher. It's usually not
too hard to separate "the compiler" from everything else, but I
don't think "the compiler" is really what you are asking about:
"the compiler" is unlikely to determine how malloc(0) behaves,
because malloc() will usually be part of "the library" and not part
of "the compiler" at all. If I may re-state your question in a
broader form without doing it too much violence, you are asking
about how to distinguish "the C implementation" from "the operating
system."
From the C Standard's point of view the question is easy: The
C implementation includes the operating system as one of its parts.
The C implementation also includes the "BIOS," the silicon, the I/O
devices, the power plant and transmission system that provide the
electricity to run it all, and in fact the entire physical Universe.
(After all, if you write an infinite loop and the implementation
collapses in a Big Crunch before completing it, the implementation
is non-conforming.)
From the operating system's point of view the question is also
easy: C is just one of the languages that can exploit the features
the operating system provides. The C compiler, its associated
libraries, the facilities that bind them all together and cause
them to execute and clean up after termination -- all these things
are either services provided by the O/S or clients that use the O/S.
The O/S has no philosophical problem about killing a runaway program
when it exceeds its CPU quota or fills up its allotted disk space or
when somebody hits CTRL-C; the O/S is Master, and that's that. (Of
course, a few levels of hypervisors and virtual machines somewhat
warp that reality, but the typical O/S reaction is to ignore the
fact that it's been virtualized, just as C ignores the fact that it
runs only at the pleasure of an O/S.)
Where is the frontier between these points of view? Like many
frontiers it is fought over unceasingly and moves back and forth
as the armies on each side double or dwindle. Much depends on the
point being argued and on who is arguing it, and there is little
hope of drawing impermeable and immutable lines. (Old joke, maybe
understandable only to New Englanders: A surveyor knocks on the
door of a New Hampshire farmer, explains that he's been checking
the accuracy of the state line, and apologizes for bringing the
farmer the bad news that he doesn't live in New Hampshire at all,
but in Massachusetts with its higher taxes. "A-well," says the
farmer, "'Taint all to the bad. Between you'n me, I'm gettin' on
in years and I won't miss them cold New Hampshire winters.")
Where should you ask your question, when you're not sure whether
it's about C or about an O/S that hosts C? One practical approach
is to ask all questions on comp.lang.c and wait to get flamed; one
or more of the flames will probably include pointers to other likely
sources of information. But although the approach may be practical
it can also be construed as abusive, so if you intend to ask more
than a few questions you might not want to risk unpopularity and
silence. So my advice (and it's only mine; others will probably
differ) is to study the FAQ, to read the newsgroup even when you're
not actively pursuing a question, and then to make the best judgment
you can.
And by the way: I thank you for asking. Sincerely, I do.
