No. If that were the case, I doubt you could interpret it at all. The
standard is written in English, and relies on a huge amount of
background knowledge about computers as well as the everyday pragmatic
interpretation of English.
You yourself are using a (rather bizarre) pragmatic rule in your own
interpretation: that because the standard does not acknowledge the
existence of other programs, then we must interpret everything as if
there weren't another program. This rule is doubly wrong: the standard
does acknowledge the existence of other programs (for example, do you
think it would bother providing files otherwise?), and the inference
itself it not justified either by common sense or explicit wording in
the standard.
Picture two boxes. One is labelled "Defining behaviour of a C program",
the other is labelled "everything else". Into which box does the
definition of free go?
If it goes into the first box, then the *defining behaviour of a C
program* is that the memory released by free is available for further
allocation - *by the C program*. Period. That is where and how it is
defined to work.
If it belongs in the other box, that the definition of free does *not*
actually define the behaviour of a C program, then free has no business
being in the standard.
Of course we need something like free, to make C as useful as it is, but
in defining how free operates, we must also remember that we are defining
not just the operation of free, but we are, in fact, creating the entire
operational definition of a C program, free simply being a part of that
definition. Which means that whatever free is defined as doing, applies
in and to the C program. Not to an OS, not to a remote server, not to
Mars, God of War; to the C program.
Free defines a behaviour *for the C program*. Not for those other
things. The defined behaviour is to make the memory available for
further allocation. Thus the memory, by the definition of free, is
available - *to the C program*. Not to the OS, not to a remote server,
not to Mars.
Nor does the standard acknowledge other programs as you assert. Your own
example fails. It does not, for example, define files in any
particularly meaningful way - it does not, for example, tell us that the
file will be stored on a disk rather than on a tape. For all that "file"
is defined, it could cause the data to be read aloud, then re-entered by
a typist on reading it.
Let's use fopen as an example. Fopen can be used to open or create a
"file", and to set certain operational modes such as "binary" mode or
"text" mode. Note, though, that it says nothing at all about what
effects any of this have on the "file" itself; these define the modes of
operation of the C program interacting with that "file".
So take text mode. It tells us nothing of how the data is stored in the
file, nor even what "file" means, other than being some external means of
recording and recalling data. When you write to the file, the standard
does not define how that data gets read or translated nor where the data
is stored; it simply defines the behaviour of the C program: a block of
data written _here_ using _this_ mode should be later readable at that
same place, in that same file, using the same mode, as the same data.
*How* this is accomplished, the standard does not say, nor does it care -
it defines the behaviour of the C program, not of files, file systems,
OSen or other creatures.
So even in your example of files, the C standard does exactly what the C
standard is for - it defines the behaviour of C programs. Not of OSen,
not of remote servers, not of gods of war, no, it defines C programs and
only C programs.
What does free do, again? It releases a portion of previously allocated
space, which is made available for further allocation. And exactly what
can the standard define such a behaviour for? Right, the C program. And
what is the defined behaviour for the C program? That the memory is
available for further allocation.
So. Do we keep free's definition within our "defining behaviour of a C
program" box? Do we toss free out of the standard and move it to the
other box? Do we - as seems to be the argument here - keep free in the C
box, but kinda, sorta, without description, definition, or indeed any
justification, decide to put half of the definition of free into the
other box?
If the latter, well, fine, let's do so. Shall we do so with other
functions, too? Shall we say, for example, that fclose, which we will
presumably agree releases resources, should be allowed to release *all*
resources, up to and including killing the entire program? Is that an
acceptable behaviour? No? But if we're going to randomly toss half our
function definitions into the other box where we have no way to define
expected behaviours, then this would be an acceptable behaviour.
We can go even further. We can note that while we define an operation
such as addition with certain requirements, if half our definitions
belong inside the other box then as far as our code is concerned, 1+1 may
actually equal 17,395 - hey, we can't define what's going on in the other
box, this is a legitimate result.
It's silly, of course, but that's the point: the whole notion of randomly
tossing half our definitions into the other box *is* silly. I am simply
pointing out that we should not do so, cannot afford to do so. Yet if we
don't, then we're left with the obvious conclusion: by the definition of
free, the C program has every right to assume the memory in question is
available, as free *guarantees* this.
If someone wants to give an actual rationale for tossing half our
definitions into the other box, of introducing chaos into our programs,
feel free, I'd love to see the reasoning behind it. Personally, I don't
think it makes much sense to do so; I prefer a standard which actually
defines, as far as possible, predictable and useful behaviour sets. The
C standard, by and large, does this now, but it does so by *not* randomly
tossing things into the other box, it does so by actually defining the
behaviours. In the case of free, it does - it defines it as making the
memory available for further allocation, and it does this in the only
context it can: the context of the C program. The C program thus *has*
the memory available for further allocation; the standard guarantees it.
That said, this will be my last post on the matter. One can only bang
one's head on the wall so long. The standard quite clearly defines a
required behaviour. That behaviour is, also quite clearly, *not* the
intended behaviour - I'm sure we all agree that the memory should, where
possible, be handed back to the OS for whatever purposes it may have. It
simply is not allowed for this to happen, though, under the current
wording.
I suspect this also means there's likely not a conforming implementation
anywhere in the known universe, but that's another matter. We've already
got people arguing for the random switching of "boxes" halfway through
the definition of a function's behaviour; I can hardly see them caring
whether an implementation is conforming or not.
