Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!udel!princeton!phoenix!pupthy2!lgy
From: lgy@pupthy2.PRINCETON.EDU (Larry Yaffe)
Newsgroups: comp.unix.wizards
Subject: Re: #defines with variable # arguments
Message-ID: <2886@phoenix.Princeton.EDU>
Date: 14 May 88 04:56:42 GMT
References: <2855@phoenix.Princeton.EDU+ <2633@tekcrl.TEK.COM>
Sender: news@phoenix.Princeton.EDU
Reply-To: lgy@pupthy2.PRINCETON.EDU (Larry Yaffe)
Distribution: na
Organization: Physics Dept, Princeton Univ
Lines: 54

In article <2633@tekcrl.TEK.COM> terryl@tekcrl.tek.com writes:
 >In article <2855@phoenix.Princeton.EDU+ (lgy@pupthy2.PRINCETON.EDU) I wrote:
 >+
 >+    Are there any versions of cpp which allow one to define macros which
 >+accept variable numbers of arguments?  I keep wishing for this every time
 >+I try to move code developed using sysV sprintf to a BSD system, so that
 >+I could do something like:	[example deleted]
 >
 >     I came across this kludge years ago, hope it helps:
 >#define	sprintf(prf)	{ Sprintf prf }
 >
 >     The TRICK is to ADD an extra level of parentheses, using it like thus:
 >
 >		sprintf( (buffer,"<what-ever-string-you-want>",<varargs>) );
 >
 >This makes cpp THINK there is only one argument to the macro; I know you
 >don't want to muck with the sources and just want to put in the #define

	Right!!

 >and be done with it, but this is the only way I know of.

    A number of people suggested variants of the above.  Unfortunately,
all of these approaches require manual editing of (large amounts of) existing
source code.  The whole point of the exercise is to be able to automate the
conversion between sysV & BSD versions of sprintf.  Regrettably, such a
stupid little inconsistency (the difference in return values) cannot be
automatically fixed using any combination of cpp, sed, or awk.

    Several other people pointed out that one shouldn't ever use the
return value of sprintf if you want maximally portable code.
True, but rewritting existing code is SO much fun :-).

 >+    Does anyone know why the folks at Berkeley chose to have their
 >+sprintf return its first argument, instead of the number of characters
 >+printed?  I can't think of any good reason for this choice, since it
 >+throws away valuable information (the # of characters printed) which
 >+is painful to reacquire.
 >
 >     How painful is a strlen???? (I.E. I really don't understand your
 >complaint).

    Well, since every implementation of sprintf I've seen counts the
number of characters printed internally, its irritating if you have to
call strlen just to recompute information that was easily available but
thrown away.  And its quite possible for the extra call to strlen to
take nearly as long as the sprintf.  If you're calling sprintf a LOT of
times, adding a call to strlen after each sprintf can be very significant.

------------------------------------------------------------------------
Laurence G. Yaffe			Internet: lgy@pupthy.princeton.edu
Department of Physics			Bitnet:   lgy@pucc
Princeton University			UUCP:     ...!princeton!pupthy!lgy
PO Box 708, Princeton NJ 08544