Xref: utzoo comp.lang.c:8177 comp.sys.ibm.pc:13171
Path: utzoo!mnetor!uunet!husc6!ut-sally!utah-cs!utah-gr!uplherc!sp7040!wsccs!terry
From: terry@wsccs.UUCP (terry)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: MSC Danger (was Re: Turbo C vs Quick C)
Message-ID: <304@wsccs.UUCP>
Date: 12 Mar 88 08:50:17 GMT
References: <389@lscvax.UUCP> <567@naucse.UUCP> <2946@dasys1.UUCP> <1082@dutesta.UUCP>
Lines: 28
Keywords: near far large small mixed
Summary: Because...

In article <1082@dutesta.UUCP>, knop@dutesta.UUCP (Peter Knoppers) writes:
> 
> Why, oh why don't the .obj files in MSDOS contain some bits telling
> the linker whether a function in the .obj file expects to be called
> with a FAR or a NEAR call. This can prevent accidentally linking
> modules compiled for different models.

	Because there is no way to set up a function such that if you call
it 'NEAR' at such-and-such an address, you can still call it 'FAR' at a prior
address.  The push's end up in the wrong order for near and far calls.  There
was a very good column on this in 'The Devil's advocate', a column carried by
several magazines, I think, and written by Stan Kelly Bootle (sp?).  I think
that fact that his Porshe liscence plate is 'MC68000' has nothing to do with
this dim view.

	Of course, the linker COULD do this, IF it were to generate code, but
linkers are not supposed to have to do that (if you can call what MSC uses
a linker :-( ).  Barring generation of appropriate code by the linker, which
would have to include translation of some previous code generated by the
compiler, such as _calls_ ;-), external refs, and so forth, as well as segment
crossing code requiring different instructions in large model, you can't do
it.  Even if you did, you 'small model' code would be using JMP's and so forth
with 16 bit addressing, rather than the 8 normally needed in small model.

	You should get a 'error: mixed code models' anyway, if you are using
a *real* compiler and linker...

				terry@wsccs