Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!garcon!uicsrd.csrd.uiuc.edu!mcdaniel
From: mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel)
Newsgroups: comp.lang.c
Subject: Re: declarations in include files:  how do YOU feel?
Keywords: declarations include
Message-ID: <1060@garcon.cso.uiuc.edu>
Date: 19 May 89 05:10:22 GMT
References: <179@larry.sal.wisc.edu> <10251@smoke.BRL.MIL> <181@larry.sal.wisc.edu> <5134@bunker.UUCP> <1008@garcon.cso.uiuc.edu> <5178@bunker.UUCP>
Sender: news@garcon.cso.uiuc.edu
Reply-To: mcdaniel@uicsrd.csrd.uiuc.edu (Tim McDaniel)
Organization: Center for Supercomputing R&D (Cedar), U. of Ill.
Lines: 67

In article <5178@bunker.UUCP> garys@bunker.UUCP (Gary M. Samuelson) writes:
>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.

I think it *can* be done.  Changing a function to a macro must be
considered carefully, as with any proposed optimization.  In other
words, will it really be an optimization, or a problem?  *Any* change
can break code.

- Was the function ever called with arguments with side effects?  If
  so, will the side effects get evaluated exactly once?
- Is the product "macro size (in bytes of machine code)" * "lexical
  number of calls per program" large?  How does "macro size" compare
  with "function call size"?
- Were users ever likely to put the function name in jump tables?  If so,
  are their compilers ANSI C compliant: if a macro name is not
  followed by "(", is it an error?
- Who are the users?  Dave and Perry down the hall, who know to come
  to you if they have any problems with -lcsrd, or all of SUN's UNIX
  customers?
- Have you documented the change?

>>That way, it's in lib.h as a macro and lib.a as a function.
>
>Then it hasn't been *replaced*, has it?

Hidden, in the sense of variable hiding:
        {int i; ... {int i; ... }}

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

I think there's something in the ANSI C standard about this -- if
library functions are implemented as macros or builtins, perhaps?
I think #undef is officially blessed for such a case, but I can't
remember any details and I can't find it in K&R2.  I guess we just
have different tastes in coding styles.

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

Let me rephrase.  "Personally" == "I'd like to know the practices of
all the C programmers in the world, but I don't, so I can only list my
own experiences."  I've see 3 function jump tables in my C programming
life, all of which included only program-defined functions (none out
of any libraries), 2 of which could have had lists of #undefs added
mechanically.

As for "lots of people" using libraries: when I think of "libraries",
I think of everything from libc.a (millions of users, indirectly) down
to libcsrd.a (a local library; dozens of users, maybe).  Changing
function -> macro works FAR better on a local scale.

Looking at your last response, Gary, I'd say we are in substantial
agreement about the basic issues involved.

--
"6:20 O Timothy, keep that which is committed to thy trust, avoiding
profane and vain babblings, and oppositions of science falsely so
called: 6:21 Which some professing have erred concerning the faith."

Tim, the Bizarre and Oddly-Dressed Enchanter  |  mcdaniel@uicsrd.csrd.uiuc.edu
            {uunet,convex,pur-ee}!uiucuxc!uicsrd!mcdaniel
            mcdaniel%uicsrd@{uxc.cso.uiuc.edu,uiuc.csnet}