Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site hcradm.UUCP
Path: utzoo!hcrvax!hcradm!mike
From: mike@hcradm.UUCP (Mike Tilson)
Newsgroups: net.lang.c
Subject: Re: Addresses of static functions
Message-ID: <1682@hcradm.UUCP>
Date: Wed, 30-Jan-85 19:54:39 EST
Article-I.D.: hcradm.1682
Posted: Wed Jan 30 19:54:39 1985
Date-Received: Fri, 1-Feb-85 04:46:11 EST
References: <360@ecr.UUCP>
Organization: Human Computing Resources, Toronto
Lines: 18

The legality of exporting the address of a static function (e.g. by passing
a pointer to another routine in another compiled file) ought to be
identical to the legality of exporting the address of a static data
item -- if one is legal then the other should also be legal.  I think
this argues that the operation should be legal.

Quite some time ago, HCR implemented a memory mapping scheme to expand the
code address range of the smaller PDP-11 processors, similar to the later
Venix version.  In earlier versions, this kind of operation caused trouble.
In our implementation we fixed the problem.  We discovered that real programs
used this feature.  A typical use involved exporting an array of function
pointers with each function being "static".  This hid the function names, which
weren't supposed to ever be called except via the pointer table.  This seemed
like a reasonable thing to do.  I don't think it should be considered
non-portable.

/  Mike Tilson
/  Human Computing Resources Corp.