Path: utzoo!attcan!uunet!yale!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: comp.lang.c
Subject: Re: declarations in include files:  how do YOU feel?
Keywords: declarations include
Message-ID: <5178@bunker.UUCP>
Date: 18 May 89 15:48:21 GMT
References: <179@larry.sal.wisc.edu> <10251@smoke.BRL.MIL> <181@larry.sal.wisc.edu> <5134@bunker.UUCP> <1008@garcon.cso.uiuc.edu>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: Bunker Ramo, an Olivetti Company, Shelton, Ct
Lines: 119

Note that the context of this discussion was the assertion that
changing a function to a macro in some library could be done "behind
the scenes;" i.e., without the user needing to be aware of the change.

In article <1008@garcon.cso.uiuc.edu> mcdaniel@uicsrd.csrd.uiuc.edu
(Tim McDaniel) writes:

>In article <5134@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes:
>>First, if a function is replaced with a macro, it is no longer in lib.a.

>What's to prevent it?  In f.c (to go into lib.a):
>        #include <lib.h>
>        #undef f
>        int f(int x, char * y) {
>        ... }
>That way, it's in lib.h as a macro and lib.a as a function.

Then it hasn't been *replaced*, has it?

Having the same symbol be both a macro and a function in the same
file belongs only in Obfuscated C contest entries.

>>Therefore, programs have to be recompiled, as opposed to merely relinking.
>Not in this scheme.  Recompiling would cause some speedup, however, as
>well as increasing the code size.

And if later I recompile for some other reason, my program changes in
ways which I didn't expect.

Also, it is possible that replacing a function with a macro could
actually make the program slower.  For example, because of its increased
size, it page faults or swaps more frequently.

>>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.

>Not in pANS C.  If "foo" is a macro that requires arguments, and
>a use of the token "foo" is not followed by a "(" token, it's not a
>macro call.

Alright, there exists at least one compiler for which my statement is
false.  So, "Any such usage *may* break with a macro."  When pANS becomes
ANS (i.e., accepted as a standard), are all the existing compilers
which don't have these new features suddenly going be transformed,
or is someone going to upgrade them (gratis)?

>Alas, "cc" under BSD 4.3 on a VAX doesn't follow that rule.

Which means that this feature, specified (presumably required)
by pANS is inherently non-portable and should therefore not be used.

I conjecture that relatively few compilers already incorporate
this feature.

>In that
>case, in usercode.c:
>        #include <lib.h>
>        ... some code ...
>        #undef f
>        int (*p)() = f;
>        ... more references to f as a parameter or as a ptr to func
>After the #undef, all references to f are function calls, not macros
>-- c'est la vie.  Or define a convention for lib.a: ptr_f is an extern
>const variable which contains a pointer to f.

The original contention, which I disputed, was that the function-to-macro
transition could be done "behind the scenes."  Your illustration supports
my position quite well.

>Personally, I use pointers to functions so infrequently...

We are talking about libraries, which are supposed to be used
by lots of people, and therefore should not cater to personal style.

> ...that I'm
>willing to type a few extra trivial keystrokes to use them.

Keystrokes which change the meaning of the program or detract
from its readability are not what I would call trivial.

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

>#undef and recompile.  I usually have to recompile with -g anyway.  If
>the problem is the macro itself or its calls (for example, side
>effects in the argument list), perhaps it was a mistake to make it a
>macro in the first place.

The very point I was trying to make, and again supports my contention
that functions should not be changed "behind the scenes."  Such changes
should only be made, if ever, after studying a lot of issues.

>>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.

>I suppose that when your vendor upgrades your OS, you read the diffs?
>:-)

Don't you?  Yes, if something has changed which has the potential to
affect my entire system, I want to know what changed, so that I can
figure out what I have to change.  If the new version of OS requires
too much work on my part, I won't upgrade, unless the new version
includes a new feature or a bug fix I can't live without.

I certainly want to see specification changes, lists of problems fixed
and features added.

> Seriously, a user can't and shouldn't be aware of *everything*
>that's going on in the implementation -- that's why libraries and data
>encapsulation/hiding are so useful.

Changing a function into a macro is not *everything*, but, as you helped
illustrate, it has the potential to require the user to make changes
in his code, and therefore is something the user needs to be aware of.

Gary Samuelson