From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13129 invoked by alias); 8 Dec 2006 06:22:59 -0000 Received: (qmail 13118 invoked by uid 22791); 8 Dec 2006 06:22:56 -0000 X-Spam-Check-By: sourceware.org Received: from smtp101.sbc.mail.mud.yahoo.com (HELO smtp101.sbc.mail.mud.yahoo.com) (68.142.198.200) by sourceware.org (qpsmtpd/0.31) with SMTP; Fri, 08 Dec 2006 06:22:48 +0000 Received: (qmail 89569 invoked from network); 8 Dec 2006 06:22:46 -0000 Received: from unknown (HELO ?68.122.9.103?) (timothyprince@sbcglobal.net@68.122.9.103 with plain) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 8 Dec 2006 06:22:46 -0000 X-YMail-OSG: ATkl36oVM1lYp1InPafL.ZUQaU5x_xlygdljnDsd_M5vLROZ7Ts.6iUv_Lmgn1POAQceUFynCCZ9BHkK3ttTQhQTK.bYlBLaN5tyk3qlPpoXKtdBpsv_pa_t9.i7yO72xIz4azim3ToxH_Yr.M8TBhFBeRa3PzF846u8cQl5QUCLoba2doXCp_rHCkNy Message-ID: <457904A4.2040203@sbcglobal.net> Date: Fri, 08 Dec 2006 06:22:00 -0000 From: Tim Prince Reply-To: tprince@myrealbox.com User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Niklaus CC: tprince@myrealbox.com, gcc-help@gcc.gnu.org Subject: Re: Undefine a library function References: <85e0e3140612070636t6959a240pd38e196a1f3c99b6@mail.gmail.com> <45782CBD.9060309@sbcglobal.net> <85e0e3140612072007y32bcb79u5bf4626956daf1ee@mail.gmail.com> In-Reply-To: <85e0e3140612072007y32bcb79u5bf4626956daf1ee@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2006-12/txt/msg00141.txt.bz2 Niklaus wrote: > On 12/7/06, Tim Prince wrote: >> Niklaus wrote: >> > Hi, >> > Like the #undef for macros , do we have a way for undefining a >> > library function like say memset. Do we have any way(like linker) so >> > that my function memset(with different arguments) are used everywhere >> > instead of library function memset. One way would be to rename my >> > function memset to mymemset or #define it . But i want to know whether >> > there is any hack or anything so that the library is included but the >> > memset used is mine instead of the library version. >> > >> >> Do you have an example where #undef doesn't accomplish what you want? >> Evidently, many standard C functions will have macro replacements in the >> standard headers used in your implementation. C standard requires >> ability to put those aside with #undef and to have an underlying >> separate library implementation, which you could attempt to preempt with >> your own version. >> It's common practice for compilers to #define memset() to a special >> library version, but not with changes in the meaning of arguments. If >> your own version is not functionally compatible with the standard >> version, you are inviting trouble by using the standard name. > > Yes here is some code. > #include > #include > > int L[10][10]; > > #undef memset > /* if i include string.h it is compilation error, If i don't include i > get warning saying conflicting > types in library function . One way would be #define memset to > mymemset or some other function but can it not be done any other way > */ > void memset(void *mem,int c, int len); > void memset(void *mem,int c, int len) > { > > int *ptr=mem; > while(len--) > *ptr++=c; > > return; > } > > > int main() > { > int n=10,i,j,k,ll=-200; > memset(L,2,100); > } > > You could #include but you would have to make yours use the same data types, with parens around memset: void (memset)(const void *mem, int c, size_t len){ char *ptr = mem; ... Of course, you would optimize by setting a value of the widest native data type (128 bit on most current CPUs) to a string of characters of value c, but you must take care of the possible remainder values at each end. In addition //off topic you would need to set a non-cached mode, where available I don't see a purpose in your strange combination of K&R and standard C definition, plus some stuff of your own. If you do mean to set an array of ints, you shouldn't name it memset(), and there's a good chance your compiler would do better with a plain for loop. Nor do I see the point of those who say any C implementation where there is a difference between size_t and int is broken, nor am I interested in discussion of it.