Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mit-eddie!mit-amt!mit-caf!vlcek
From: vlcek@mit-caf.MIT.EDU (Jim Vlcek)
Newsgroups: comp.lang.c
Subject: Re: declarations in include files:  how do YOU feel?
Keywords: declarations include
Message-ID: <2337@mit-caf.MIT.EDU>
Date: 14 May 89 00:11:51 GMT
References: <179@larry.sal.wisc.edu> <10251@smoke.BRL.MIL> <181@larry.sal.wisc.edu>
Reply-To: vlcek@mit-caf.UUCP (Jim Vlcek)
Organization: Microsystems Technology Laboratories, MIT
Lines: 26

In article <181@larry.sal.wisc.edu> jwp@larry.sal.wisc.edu.UUCP
(Jeffrey W Percival) writes: 

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

>Is that interpretation unflawed?

If what was once a function is turned into a macro, programs which
passed arguments with side effects to the function may not work
correctly with the macro.  You know the tune:

#define square(x) ((x)*(x))  /* Used to be a function ... needed speed */

y = square(++i);

Any macro->function sleight of hand had best not take place behind the
scenes, and in fact should probably not take place at all.  Going the
other direction is probably considered safe, although some programs
may have depended upon the side effects of the macro which is now a
function.  Probably anyone who does so deserves to suffer, though...

Jim Vlcek (vlcek@caf.mit.edu  uunet!mit-caf!vlcek)