Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!cmcl2!seismo!brl-adm!brl-smoke!smoke!rbj@icst-cmr.ARPA From: rbj@icst-cmr.ARPA (root) Newsgroups: net.lang.c Subject: Re: C Builtin Funxions Message-ID: <205@brl-smoke.ARPA> Date: Tue, 22-Apr-86 16:54:32 EST Article-I.D.: brl-smok.205 Posted: Tue Apr 22 16:54:32 1986 Date-Received: Thu, 24-Apr-86 07:21:38 EST Sender: news@brl-smoke.ARPA Lines: 61 > From roger@ll-sst Sun Apr 20 15:31:29 1986 > > 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 redefining putc will have no effect on printf... > > Wayne > > > Silly me! I *axually* believed the UNIX documentation! I quote from > > man 3 printf: > > > > ... Characters generated by printf are printed by putc(3S). > > "*Axtually* the documentation is correct!" [The sound of one defending > sacred writ from the unfaithful.] But, well, it's true. Printf does > call putc, but [I quote from man 3 putc]: > > ... BUGS > Because it is implemented as a macro, \fIputc\fR ... > > [a great place to find it documented, no?] and, better, but still not > in a place it will jump out at you, [man 3s intro]: > > ... The in-line macros \fIgetc\fR and \fIputc\fR(3S) handle characters > quickly. The higher level routines [list including printf] all use > \fIgetc\fR and \fIputc\fR ... > > Once putc has been expanded in-line, redefining it elsewhere won't have > full effect. Just as in your better example, you'd have to recompile > printf (and then where's portability? ...). > > Yrs, Roger Silly me! I *axually* goofed! I got confused between `putc' and `putchar', which altho defined as a macro, is also a real funxion as well because it predated the stdio library. Sigh. Allow me to start from square one and appeal to the higher principles I was attempting to demonstrate by my errant example. I don't want the compiler taking the liberty of expanding ANY funxions inline unless I direct it do do so via a macro or some kind of #pragma that specifys inline expansion! Compilers DO NOT know about specific funxion calls! Someone suggested that `putc' could put the char into a register and make a system call. So could `putc.s'. As for portability, I SUPPLIED the funxion with my code, so it does EXACTLY what I say it does. If it is legal portable C, it ports! As to my friend Ben Cranston's suggestion that I should use `myprintf' and `myputchar', this is a very good idea, lest we forget what the funxion really does. However, this may not always be an option where objects but no source is available. Hiya Ben! (Root Boy) Jim Cottrell "One man gathers what another man spills"