Re: Undefine a library function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Aspect-oriented programming is mostly used in Java language. Is there
any AOP-enabled C compiler and linker?


2006/12/8, Michael Gong <mwgong@xxxxxxxxxxxxxx>:
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.
>




--
Sai

[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux