From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Douglas A. Gwyn" <DAGwyn@null.net>
Message-ID: <3C8593A3.37C00EB9@null.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <20020305095507.EEF2519AAA@mail.cse.psu.edu>
Subject: Re: [9fans] plan or side effect
Date: Wed,  6 Mar 2002 09:52:03 +0000
Topicbox-Message-UUID: 60308cc4-eaca-11e9-9e20-41e7f4b1d025

"Fco.J.Ballesteros" wrote:
> If there are more efficient (but still correct) ways, just
> replace the implementation of strcpy. And let the programs using
> strcpy call strcpy without a preprocessor mess. cf. The Practice
> of Programming (A "must" read).

The usual reason for the "preprocessor mess" is that generation
of the function linkage itself needs to be avoided.  E.g.
	extern char *strcpy(char *dst, const char *src);
	#define strcpy(a,b) __builtin_strcpy(a,b)
(The first line is in case the user invokes the actual function;
there are a couple of ways he can do that.)
The "inline" facility may be able to replace some of this, but it's
still no substitute for intrinsics.

Here is another example that has really sped up some searching
applications, therefore was worth doing despite being "unclean":
	#define StrEq(a,b) (*(a)==*(b) && strcmp((a)+1,(b)+1)==0)
This has the drawback that the arguments mustn't have side effects.