#undef for function

[Sachin]

hi,
Can i use #undef for undefining a function definition and use my
function instead?

like described below

#undef somefunction1

#define somefunction1(a ,b) myfunction1(a,b )

If yes what effect will it have on the undefined function code? can i
use the same for standard C library function?

Sachin

[Richard Bos]

Re: #undef for function

"Sachin" <sachinpandhare @gmail.com> wrote:
[color=blue]
> Can i use #undef for undefining a function definition and use my
> function instead?[/color]

You can only use #undef on macros. If your function name has been
#declared as a macro, this will work (FSVO - see below); if it has been
declared as an ordinary function declaration, it will do nothing.
[color=blue]
> #define somefunction1(a ,b) myfunction1(a,b )[/color]

This, however, you can always do. It's hairy, though.
[color=blue]
> If yes what effect will it have on the undefined function code?[/color]

None. Except that it will never actually be refered to in your code, so
will probably not be linked into the executable.
[color=blue]
> can i use the same for standard C library function?[/color]

The macro trick, yes. In fact, a compiler's Standard headers often do.
What you cannot portably do is to define a _function_ with the same name
as a library function. Macros, however, are allowed. And even hairier
than re-#defining your own functions. Caveat hacker!

Richard

[Eric Sosman]

Re: #undef for function

Richard Bos wrote:
[color=blue]
> "Sachin" <sachinpandhare @gmail.com> wrote:
>
>[color=green]
>>Can i use #undef for undefining a function definition and use my
>>function instead?[/color]
>
>
> You can only use #undef on macros. If your function name has been
> #declared as a macro, this will work (FSVO - see below); if it has been
> declared as an ordinary function declaration, it will do nothing.
>
>[color=green]
>>#define somefunction1(a ,b) myfunction1(a,b )[/color]
>
>
> This, however, you can always do. It's hairy, though.
>
>[color=green]
>>If yes what effect will it have on the undefined function code?[/color]
>
>
> None. Except that it will never actually be refered to in your code, so
> will probably not be linked into the executable.
>
>[color=green]
>>can i use the same for standard C library function?[/color]
>
>
> The macro trick, yes. In fact, a compiler's Standard headers often do.
> What you cannot portably do is to define a _function_ with the same name
> as a library function. Macros, however, are allowed. And even hairier
> than re-#defining your own functions. Caveat hacker![/color]

If the goal is to replace a Standard function with
your own implementation, note that the macro can only
affect code that is compiled with the macro definition
in place. If your code calls log() and you use a macro
to have it call my_log() instead, that's fine -- but if
the implementation of pow() calls log(), it will still
use log() and not my_log().

In my experience, wholesale overriding of function
names (from the Standard library or from elsewhere in
your own program) is a quick-and-dirty approach. It's
quick and convenient, but eventually the dirt will show.
Better to edit your source so it calls my_log() explicitly;
you'll probably wind up doing so eventually anyhow.

Horror story from a large program I once worked with:
The system-provided malloc() and friends performed poorly
with the amount of memory we used and the patterns in which
it tended to get fragmented. Some bright laddie solved the
problem by implementing a memory-management package more
suited to our program's habits of memory usage, and then
used macros to rename all the malloc(), free(), ... calls
so they went to the replacement package instead. Fine.

... for a while. Then somebody else observed that in
one subsystem of the program there was an atypical pattern
of memory use, where the original malloc() worked better
than the replacement. He added #undef's to the appropriate
set of modules, so calls to malloc() and friends within that
subsystem went to the "real" library while those in other
parts of the program went to our replacement versions. Still
fine.

... for a while longer. Then we decided to add a user-
accessible scripting language to the product, and this entailed
going into all the subsystems and adding various kinds of hooks
to register a system's callable services, provide for callbacks
to user-supplied functions, and so on. Naturally, a lot of
these things involved dynamically-allocated memory -- and when
Subsystem A obtained memory from the "real" malloc() and handed
it to Subsystem B, and then B tried to resize it with the
replacement realloc() ... Well, that's when the fertilizer
hit the air circulator.

Use the #define technique for quick-and-dirty hacks like
introducing instrumented versions during debugging, but don't
rely on it for "serious" code. The code *will* develop, and
the fakery *will* eventually make more trouble than it saved.

--
Eric Sosman
esosman@acm-dot-org.invalid

[Peter Ammon]

Re: #undef for function

Richard Bos wrote:[color=blue]
> "Sachin" <sachinpandhare @gmail.com> wrote:
>[color=green]
>> Can i use #undef for undefining a function definition and use my
>> function instead?[/color]
>
> You can only use #undef on macros. If your function name has been
> #declared as a macro, this will work (FSVO - see below); if it has been
> declared as an ordinary function declaration, it will do nothing.
>[color=green]
>> #define somefunction1(a ,b) myfunction1(a,b )[/color]
>
> This, however, you can always do. It's hairy, though.
>[color=green]
>> If yes what effect will it have on the undefined function code?[/color]
>
> None. Except that it will never actually be refered to in your code, so
> will probably not be linked into the executable.[/color]

/* Far away, in a distant translation unit, untold riches
* await any hero brave enough to do battle with the evil
* C. P. Reprocessor */

const char* get_the_riches( void) {
return "one million gold coins (chocolate)";
}

/* But oh no! The cackling C. P. Reprocessor has set a devious
* trap for our intrepid hero! If s/he is not careful, s/he shall
* be surely carried off by squawking nasal demons! */

#define get_the_riches( ) *(int*)(0xCACL)

/* Alas! We begin our story with trepidation.
* Will our hero fall for the trap? Is there no hope for obtaining
* the delicious dubloons? */

int main(void) {

/* Amazing! Our observant hero has deftly applied a powerful
* technique from the CLC sages known as the function pointer.
* The cowed C. P. Reprocessor is defeated! */

(get_the_riches )();

/* Sweet indeed is the ripe, tangy taste of victory.
* Our hero returns successful */

return 0;
}

-Peter

--
Pull out a splinter to reply.