Undefining a libary function could be done very easily by using
aspect-oriented-programming.
----- Original Message -----
From: "Tim Prince" <timothyprince@xxxxxxxxxxxxx>
To: "Niklaus" <niklaus@xxxxxxxxx>
Cc: <tprince@xxxxxxxxxxxxx>; <gcc-help@xxxxxxxxxxx>
Sent: Friday, December 08, 2006 1:22 AM
Subject: Re: Undefine a library function
> Niklaus wrote:
>> On 12/7/06, Tim Prince <timothyprince@xxxxxxxxxxxxx> 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<stdio.h>
>> #include<string.h>
>>
>> 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 <string.h> 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.
>
