Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watmath.UUCP
Path: utzoo!watmath!kpmartin
From: kpmartin@watmath.UUCP (Kevin Martin)
Newsgroups: net.lang.c
Subject: Re: Addresses of static functions
Message-ID: <11388@watmath.UUCP>
Date: Fri, 8-Feb-85 15:06:41 EST
Article-I.D.: watmath.11388
Posted: Fri Feb  8 15:06:41 1985
Date-Received: Sat, 9-Feb-85 05:46:48 EST
References: <360@ecr.UUCP>
Reply-To: kpmartin@watmath.UUCP (Kevin Martin)
Organization: U of Waterloo, Ontario
Lines: 21
Summary: 

In article <360@ecr.UUCP> peterc@ecr.UUCP (Peter Curran) writes:
>The original question was, "Is it OK to take the address of a >>static<<
>function, and pass it to a separately-compiled function?"
>
>Saying the answer is "no" appears to allow the compiler to take advantage of
>the fact to optimize the calling sequence...
>
>Saying the answer is "yes" means that I don't have to declare the comparison
>function used deep inside an implementation of an abstract data type to be
>external, even though its only use is to pass its address to "qsort", and it
>shouldn't be visible to any of the users of the data type.

Seems to me the correct answer is 'yes'. Any time you take the address of
*any* function, you need to ensure that the function accepts the 'long'
calling sequence, and that you generate a pointer that is usable anywhere.

This doesn't stop you from generating a function with *both* a fast and slow
entry (if your architecture and stack design allow it), and using the slow entry
for generating the pointers for (possibly) external calls, but calling the
quick entry entry when you call the function directly.
                  Kevin Martin, UofW Software Development Group