Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!twwells!bill
From: bill@twwells.com (T. William Wells)
Newsgroups: comp.lang.c
Subject: Re: The free() thing and function names
Message-ID: <1989Sep15.202109.4888@twwells.com>
Date: 15 Sep 89 20:21:09 GMT
References: <1989Sep14.022055.5961@twwells.com> <841@uniol.UUCP>
Organization: None, Ft. Lauderdale, FL
Lines: 44

In article <841@uniol.UUCP> lehners@uniol.UUCP (Joerg Lehners) writes:
: I don't like this idea at all.
: Don't hardcode any (even standard) functions into the compiler.
: What about writing my own free() function, possibly with a completly
: different semantic ?

Much too late. The dpANS has given compiler writers licence to do
pretty much whatever they want in order to implement the functions
that are specified in the library section of the standard. This
doesn't mean that you won't be able to write your own free with
whatever semantics you want, but it does mean that it won't be
portable and it does mean that you will have no right to complain if
you can't make it work with some conforming compiler.

: The compiler has no chance to detect such a case on most systems, because
: compilation and linkage are independent (is this independence standardized
: at all ??).

However, the dpANS does give the compiler writer the means whereby he
can pretty much enforce this if he really wants to. For example, the
compiler writer could give a compile error if you named an external
function or external variable "free".

: What does the standard say about standardized function overriding ?

You can't portably override the functions in the library. Moreover,
there is a whole host of names that you can't use portably in certain
circumstances. I've got a list somewhere, perhaps I'll dig it out if
no one else posts one.

BTW, I too am not very happy about this: it effectively adds a whole
bunch of keywords to the language. Some of which one has no reason to
know exists. Well, it is much too late, and I haven't a suggestion to
fix it; I thought I did, but on further inspection, discovered a
fatal flaw. So now I'll just grumble about this language deficiency
and learn to live with it. (Oh yes, Standard C is much better about
this than K&R C: at least with Standard C you can look up in one
document the names you have to beware of; with K&R C you have to know
the names on every system you want to be portable to. And hope they
don't change without warning.)

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill@twwells.com