* Undefine a library function
@ 2006-12-07 14:36 Niklaus
2006-12-07 15:01 ` Tim Prince
0 siblings, 1 reply; 7+ messages in thread
From: Niklaus @ 2006-12-07 14:36 UTC (permalink / raw)
To: gcc-help
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.
Regds
Nik
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefine a library function
2006-12-07 14:36 Undefine a library function Niklaus
@ 2006-12-07 15:01 ` Tim Prince
2006-12-08 4:07 ` Niklaus
0 siblings, 1 reply; 7+ messages in thread
From: Tim Prince @ 2006-12-07 15:01 UTC (permalink / raw)
To: Niklaus; +Cc: gcc-help
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefine a library function
2006-12-07 15:01 ` Tim Prince
@ 2006-12-08 4:07 ` Niklaus
2006-12-08 6:22 ` Tim Prince
0 siblings, 1 reply; 7+ messages in thread
From: Niklaus @ 2006-12-08 4:07 UTC (permalink / raw)
To: tprince; +Cc: gcc-help
On 12/7/06, Tim Prince <timothyprince@sbcglobal.net> 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);
}
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefine a library function
2006-12-08 4:07 ` Niklaus
@ 2006-12-08 6:22 ` Tim Prince
2006-12-08 14:05 ` Michael Gong
0 siblings, 1 reply; 7+ messages in thread
From: Tim Prince @ 2006-12-08 6:22 UTC (permalink / raw)
To: Niklaus; +Cc: tprince, gcc-help
Niklaus wrote:
> On 12/7/06, Tim Prince <timothyprince@sbcglobal.net> 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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefine a library function
2006-12-08 6:22 ` Tim Prince
@ 2006-12-08 14:05 ` Michael Gong
2006-12-08 15:25 ` Sai LUO
[not found] ` <7079227c0612080724o5dd7f374mf51c8cd2b344e8c6@mail.gmail.com>
0 siblings, 2 replies; 7+ messages in thread
From: Michael Gong @ 2006-12-08 14:05 UTC (permalink / raw)
To: tprince, Niklaus; +Cc: tprince, gcc-help
Undefining a libary function could be done very easily by using
aspect-oriented-programming.
----- Original Message -----
From: "Tim Prince" <timothyprince@sbcglobal.net>
To: "Niklaus" <niklaus@gmail.com>
Cc: <tprince@myrealbox.com>; <gcc-help@gcc.gnu.org>
Sent: Friday, December 08, 2006 1:22 AM
Subject: Re: Undefine a library function
> Niklaus wrote:
>> On 12/7/06, Tim Prince <timothyprince@sbcglobal.net> 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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefine a library function
2006-12-08 14:05 ` Michael Gong
@ 2006-12-08 15:25 ` Sai LUO
[not found] ` <7079227c0612080724o5dd7f374mf51c8cd2b344e8c6@mail.gmail.com>
1 sibling, 0 replies; 7+ messages in thread
From: Sai LUO @ 2006-12-08 15:25 UTC (permalink / raw)
To: gcc-help; +Cc: tprince, Niklaus
Aspect-oriented programming is mostly used in Java language. Is there
any AOP-enabled C compiler and linker?
2006/12/8, Michael Gong <mwgong@cs.utoronto.ca>:
> Undefining a libary function could be done very easily by using
> aspect-oriented-programming.
>
>
> ----- Original Message -----
> From: "Tim Prince" <timothyprince@sbcglobal.net>
> To: "Niklaus" <niklaus@gmail.com>
> Cc: <tprince@myrealbox.com>; <gcc-help@gcc.gnu.org>
> Sent: Friday, December 08, 2006 1:22 AM
> Subject: Re: Undefine a library function
>
>
> > Niklaus wrote:
> >> On 12/7/06, Tim Prince <timothyprince@sbcglobal.net> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Undefine a library function
[not found] ` <7079227c0612080724o5dd7f374mf51c8cd2b344e8c6@mail.gmail.com>
@ 2006-12-08 15:32 ` Michael Gong
0 siblings, 0 replies; 7+ messages in thread
From: Michael Gong @ 2006-12-08 15:32 UTC (permalink / raw)
To: Sai LUO, Michael Gong; +Cc: gcc-help
www.aspectc.net
We have a research project : AspectC. It is similiar with AspectJ, but
is targeted to C. It is a source-to-source transformation tool, so no
special linker is required.
Actually, there are some other projects of applying AOP on C. You could
find @ : http://www.aosd.net/wiki/index.php?title=Aspects_in_C
----- Original Message -----
From: "Sai LUO" <sailuo@gmail.com>
To: "Michael Gong" <mwgong@cs.toronto.edu>
Sent: Friday, December 08, 2006 10:24 AM
Subject: Re: Undefine a library function
> Aspect-oriented programming is mostly used in Java language. Is there
> any AOP-enabled C compiler and linker?
>
> 2006/12/8, Michael Gong <mwgong@cs.utoronto.ca>:
>> Undefining a libary function could be done very easily by using
>> aspect-oriented-programming.
>>
>>
>> ----- Original Message -----
>> From: "Tim Prince" <timothyprince@sbcglobal.net>
>> To: "Niklaus" <niklaus@gmail.com>
>> Cc: <tprince@myrealbox.com>; <gcc-help@gcc.gnu.org>
>> Sent: Friday, December 08, 2006 1:22 AM
>> Subject: Re: Undefine a library function
>>
>>
>> > Niklaus wrote:
>> >> On 12/7/06, Tim Prince <timothyprince@sbcglobal.net> 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
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-12-08 15:32 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-07 14:36 Undefine a library function Niklaus
2006-12-07 15:01 ` Tim Prince
2006-12-08 4:07 ` Niklaus
2006-12-08 6:22 ` Tim Prince
2006-12-08 14:05 ` Michael Gong
2006-12-08 15:25 ` Sai LUO
[not found] ` <7079227c0612080724o5dd7f374mf51c8cd2b344e8c6@mail.gmail.com>
2006-12-08 15:32 ` Michael Gong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).