The free() thing and function names

[Barry Margolin]

In article <11073 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:
>In article <841 at uniol.UUCP> lehners at uniol.UUCP (Joerg Lehners) writes:
>>Don't hardcode any (even standard) functions into the compiler.
>>What about writing my own free() function, possibly with a completly
>>different semantic ?
>You absolutely must NOT do that in a hosted implementation.  Several
>library routines may depend, not only on the documented semantics of
>an external function named free(), but also on implementation-specific
>internal properties of the free() implementation.  If you provide your
>own external function named free(), you can break the implementation.

I thought implementation-provided libraries were required to use an
internal, underscore-prefixed name for all the standard library
functions, precisely to allow users to override the normal names.

>>What does the standard say about standardized function overriding ?
>
>A program that does that is not strictly conforming.

I thought you were allowed to do this, provided you first #undefine
the name.  Implementations are permitted to implement any of the
standard library functions as macros; if an implementation wished to
open-code certain library calls, it would define them as macros for
implementation-dependent keywords (in the underscore-prefixed
namespace, which the standard explicitly reserves for the
implementation) which are recognized by the compiler.

I remember these rules being discussed quite a bit a few years ago.
Did they not make it into the pANS?

Barry Margolin
Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar