Xref: utzoo comp.sys.m6809:708 comp.lang.c:8008
Path: utzoo!mnetor!uunet!husc6!hao!ames!amdahl!nsc!voder!wlbr!pete
From: pete@wlbr.EATON.COM (Pete Lyall)
Newsgroups: comp.sys.m6809,comp.lang.c
Subject: Re: Don't use Scanf()
Message-ID: <4581@wlbr.EATON.COM>
Date: 11 Mar 88 17:53:52 GMT
References: <2401@ihwpt.ATT.COM> <320@c10sd1.StPaul.NCR.COM> <1185@ucsfcca.ucsf.edu>
Reply-To: pete@wlbr.UUCP (0000-Pete Lyall)
Organization: Eaton IMS, Westlake Village, CA
Lines: 32
Keywords: C stdio library

In article <1185@ucsfcca.ucsf.edu> roland@rtsg.lbl.gov (Roland McGrath) writes:
>One real stupidity I've seen many, many times is the
>over-use of printf.  
>
>For example:
>	printf("Hello world!\n");
>Haven't you ever heard of puts????
>	puts("Hello world!");	/* note the newline is appended	*/

Hmmmm. What about the case where 'printf()' is already used elsewhere
in the program for argument substitution and formatting? Wouldn't
this merely be just another subroutine (in RMA) call to the already
included 'printf' function? If that is in fact the case, the I would
suspect that the use of 'puts()' or 'fputs()' would actually add code,
unless of course the 'puts()' or 'fputs()' are used internally by
'printf()'. I doubt that this is the case (my local unix.wizard says
the 'puts' brothers aren't used by 'printf()', at least not here).

Another item you might consider... if you're using a coco3 under level
II, the minimum allocation segment is 8k under the memory management
scheme. Os9 doesn't care if the program is 79 bytes or 7900 bytes, it
is still going to allocate 8192 for the program segment (or some
multiple thereof). Of course the counter arguments are that if you're
byte-fighting to get within the next lower 8k notch, removal of *all*
printf's may do you some good (approximately 3-5k).  Also, you could
save some disk space by removing *all* printf's.


-- 
Pete Lyall (OS9 Users Group VP)|  DELPHI: OS9UGVP  |  Eaton Corp.(818)-706-5693
Compuserve: 76703,4230 (OS9 Sysop) OS9 (home): (805)-985-0632 (24hr./1200 baud)
Internet: pete@wlbr.eaton.com      UUCP: {ihnp4,scgvax,jplgodo,voder}!wlbr!pete