Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uhccux!julian
From: julian@uhccux.uhcc.Hawaii.Edu (Julian Cowley)
Newsgroups: comp.lang.c
Subject: Re: Microsoft C far pointer dereferencing
Message-ID: <9041@uhccux.uhcc.Hawaii.Edu>
Date: 17 Aug 90 03:41:29 GMT
References: <9031@uhccux.uhcc.Hawaii.Edu> <5843@uceng.UC.EDU>
Organization: University of Hawaii at Manoa
Lines: 34

In article <5843@uceng.UC.EDU> mfinegan@uceng.UC.EDU (michael k finegan) writes:
>julian@uhccux.uhcc.Hawaii.Edu (Julian Cowley) writes:
>>PutPixel (int x, int y, unsigned char c)
>>{
>>  unsigned char far *mem;
>>
>>  FP_SEG (mem) = 0xa000;
>>  FP_OFF (mem) = 320 * y + x;
>>
>>  *mem = c;		/* <-- this line gives a run-time error */
>>}
>
>If you look at the manual page again, it says the use of FP_*** is library
>(i.e. memory model) dependent. For small and medium models, these macros
>will only work if the pointer mem is in the default data segment. You have
>it on the stack (subroutine automatic variables) - is that the problem ?

Unfortunately, no.  Moving the declaration outside of the
function body makes no difference in the behavior, even using
the large memory model.  I'm afraid that I have virtually no
knowledge of how Intel addressing works other than the
segment:offset concept, and even a quick scan through the
Microsoft manuals reveals none of the hocus-pocus assembly
language techniques that differentiate the memory models.
Since this is obviously moving outside the realm of comp.lang.c,
I'm going to repost to one of the comp.sys.ibm.pc.* groups.
Thanks to all who responded.

[ps. that was using quick c, not microsoft c proper...possible bug?]

julian cowley
university of hawaii at manoa
julian@uhccux.uhcc.hawaii.edu
julian@uhccux.bitnet