🚀 go-pugleaf

In article <138@pigs.UUCP> haugj@pigs.UUCP (John F. Haugh II) writes:
[static functions must be *declared* static as well as *defined* that
way (so says the dpANS); and]
>Thinking back (WAY BACK) I do recall this ``feature'' being discussed
>as a way to inform the compiler that the function linkage may be
>different for static functions vs. global functions [ namely that
>certain segmented machines may be able to generate `NEAR CALL's vs `FAR
>CALL's. ]

Since there is nothing that prohibits taking the address of a static
function, to make static functions `near' rather than `far' (on the
80[12]86) requires reading the entire source file before generating
code (to ensure that no other function makes the address of the static
function available outside the current file).  Hence the restriction on
declarations is not useful for this purpose.

(The assumption was that if the declaration matched the definition, the
compiler could emit the `near' code `on the fly'.  Since this is false,
if the compiler is to use near calls, it must do enough work that
resolving the declaration against the definition would be trivial.[*]
There may be *other* good reasons to require that the declaration match
the definition, such as helping the human reader.)

[*] There is another method:  One could wrap all `near' entry points with
`far' versions.  Again, this does not require that the declaration match
the definition.

(The discussion was not very long ago---perhaps a year or two.  I
remember posting a very similar refutation of the `near call' argument.)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris