static -> static near

[Jeff Alvidrez]

In article <7836 at cup.portal.com> Howard_Reed_Johnson at cup.portal.com writes:
>
>The near qualifier instructs the 80x86 compiler to expect to be
>called with a near call (as opposed to a far call).
>
>The two are not equivalent, since the address of 'func' can be
>given to other program modules via a pointer to function:
>
>		int (*pfi)() = func;

More significantly, the linker will fail with a segment fixup error
if you compile in a large code model and try to call a near function
from code in another source file.  This is because the large models
on most PC C compilers make a separate code segment for each source
file (module) and saves space in the object code for a 32-bit (far) address
for all function calls.  A near function's object file information has only
a 16-bit address, so the linker will throw its hands up in despair,
and you will be left without an executable.

It is a good thing that the linker fails here, however, because if it
did not, the near function would use a near return, leaving the segment
address of the far caller on the stack and returning to who knows where.

I think prototypes help prevent such things, but of course you have to
be disciplined enough to use them (yuk).  MSC has a flag that generates
them automatically, but in TC you just have to do it manually.

This may have slightly different results on different compilers, but this
is what happens in Turbo C.

I believe most of this stuff is in the sections of the MSC/TC manuals
on memory models.  Codeview also helps a lot when you are in doubt;
seeing the code a compiler generates and watching it in action can go
a long way to understanding what these language constructs REALLY mean.

It is unfortunate that we have to be concerned with these things, but
blame that on IBM's use of a segment-addressing CPU; on most virtually
addressed systems, people can go through life believing that C is
a low-level language because it gets about as close to the underlying
architecture as the average programmer needs to go.

/jra

PS To use Codeview with Turbo C you have to generate assembler source
and proceed from there as if you were assembling (with Microsoft MASM)
for Codeview.  Not source level, but better than SYMDEB or printf().
When o when will we see Borland's AMAZING debugger?

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jeff Alvidrez
alvidrez at heathcliff.cs.columbia.edu

The opinions expressed in this article are fictional.  Any resemblence
they may bear to real opinions (especially those of Columbia University)
is purely coincidental.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-