declarations in include files: how do YOU feel?

[Gary M. Samuelson]

In article <181 at larry.sal.wisc.edu> jwp at larry.sal.wisc.edu.UUCP (Jeffrey W Percival) writes:
>And besides, I think I thought up another reason:  what if the maintainer
>of the lib.a decides to re-implement an existing function as a macro,
>for example.  If the user has the thing appearing in an extern statement,
>it might break.  If the user relies on the lib.h file to "make everything
>OK", then the macro/function sleight of hand can proceed behind the scenes.

Not necessarily.

There are other cases where changing a function to a macro
can cause problems:

First, if a function is replaced with a macro, it is no longer in lib.a.
Therefore, programs have to be recompiled, as opposed to merely relinking.
This can be ameliorated by well-written make files (assuming make is
available), but should be taken into account when considering changing
a function to a macro.

Second, a pointer to a function can be passed as a parameter, stored in
a variable, and so forth.  Any such usage will break with a macro.

Third, the size of the program increases as you replace functions
with macros.  Maybe that's not an issue in your particular case, but
in some cases it is, and should be taken into account.

Debugging is also affected adversely; ever try to put a breakpoint
at a macro?

In short, please do not change things by "sleight of hand" or "behind
the scenes."  If you (generic "you" here) change something I use,
I want to know as precisely as possible why, preferably in advance.
And if you are inclined to say that a particular change won't have
any effect on me, well, I prefer that you let me be the judge of that.

Gary Samuelson