Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site utcsri.UUCP
Path: utzoo!utcsri!greg
From: greg@utcsri.UUCP (Gregory Smith)
Newsgroups: net.lang.c
Subject: Re: C Builtin Funxions
Message-ID: <2569@utcsri.UUCP>
Date: Wed, 16-Apr-86 15:45:28 EST
Article-I.D.: utcsri.2569
Posted: Wed Apr 16 15:45:28 1986
Date-Received: Wed, 16-Apr-86 16:22:51 EST
References: <2564@brl-smoke.ARPA> <170@cad.UUCP>
Reply-To: greg@utcsri.UUCP (Gregory Smith)
Organization: CSRI, University of Toronto
Lines: 21
Summary: 

In article <170@cad.UUCP> faustus@cad.UUCP (Wayne A. Christopher) writes:
>In article <2564@brl-smoke.ARPA>, rbj@icst-cmr.ARPA (root) writes:
>> Some of us know what we're doing. One sees lots of redefinitions of
>> things like `putc' in {VM,}UNIX code. It is often desirable to use
>> high level funxions (printf) while hacking up a lower level one.
>
>Of course, you realize that redefining putc will have no effect on printf...
>
>	Wayne
The above statement is non-portable, isn't it? If  the new standard
says that putc() has to be a macro, then I'm wrong but..
If (a) putc is a real function and (b) printf calls it, then printf
will be affected by a redefinition of putc. And (a) almost implies (b).

This weirdness seems to be a plus point for reserving any library functions
that may or may not be macros.

-- 
"If you aren't making any mistakes, you aren't doing anything".
----------------------------------------------------------------------
Greg Smith     University of Toronto      UUCP: ..utzoo!utcsri!greg