Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!brl-tgr!tgr!hadron!jsdy@SEISMO.ARPA
From: jsdy@SEISMO.ARPA
Newsgroups: net.lang.c
Subject: Re: Addresses of static functions
Message-ID: <8580@brl-tgr.ARPA>
Date: Sun, 24-Feb-85 19:02:36 EST
Article-I.D.: brl-tgr.8580
Posted: Sun Feb 24 19:02:36 1985
Date-Received: Wed, 27-Feb-85 07:09:14 EST
Sender: news@brl-tgr.ARPA
Lines: 23

Suggestion to make this usable (people who don't understand or WANT to
understand the 80*86 have my full understanding & envy, and may turn to
the next message.):
The problem seems to be that static functions, under VENIX, are
compiled as local to the segment and therefore have a short return
sequence rather than a long return sequence.  Well, the '&' unop, when
applied to a function, produces a pointer whose only use is as an
object from which to make an indirect call.  It need not be the exact
address in memory of the routine (although debuggers prefer this GREAT-
LY!).  Further, a static can only be accessed within its own module
(obviously).  Well, let's say that all function-addresses must be long
pointers, and that calls indirected from such pointers must ne long
calls.  Well, we can still have local static functions, if we think
it's worth it.  Just have, for each static whose address is taken in
the module, a long-return (unnamed) function whose sole purpose is
to copy the args back onto the stack and do a short-call to the static
routine.  'Course, this will cause problems with varargs functions ...

Maybe it would just be better to make all functions long-return
functions.

;-Z
.r .sig