Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!xanth!kremer
From: kremer@cs.odu.edu (Lloyd Kremer)
Newsgroups: comp.lang.c
Subject: Re: Microsoft C 5.1 - bug
Summary: more 4-byte pointer problems
Message-ID: <8489@xanth.cs.odu.edu>
Date: 15 Apr 89 14:58:03 GMT
References: <1051@dgbt.uucp> <28956@apple.Apple.COM>
Organization: Old Dominion University, Norfolk, Va.
Lines: 42



In article <28956@apple.Apple.COM> austing@Apple.COM (Glenn L. Austin) writes:

>I found that anytime I used 32-bit pointers in MSC5.1, the code would compile
>correctly, but that the segment values would not be assigned correctly from
>pointer to pointer.  The symptoms I encountered were random crashes, not from
>my code, but from interrupts.  Putting the code through an I2ICE (what a nice
>debugging tool!) showed that even though the segment was set correctly on my
>first pointer (from malloc), re-assigning it later to another pointer caused
>the segment to always be set to 0.  The only solution I (and MS) found was to
>move the segment and offset separately.


I too have had problems with 4-byte pointers apparently "forgetting" their
segment values when using MSC 5.1, but in my experience the pointers would
magically acquire the default data segment (register DS), rather than
segment 0.

I was compiling under large model, where both code and data pointers are
4 bytes by default (unless the 'near' keyword is used).  In one section
of code, comparisons through pointers were not working, since half the
objects being compared were in a far data segment, and the compiled code
was apparently assuming that all were in the default segment.  The pointers
happened to be char *'s.  I found that the stopgap solution was to include
an explicit cast to 'char far *' at every pointer reference within the
troublesome code section.  I felt somewhat miffed at having to keep
"reminding" the compiler that it was in large model.

In light of a previous posting on this subject, it appears that the problem
was not so much in "forgetting" to carry the pointer segment during code
generation, but in losing it in subsequent overzealous optimizing.

I concluded that the only reason the vast majority of large model code works
is that although each function is in a different segment, the data are
usually all kept in the default data segment.  I had a few large objects
that had been farmed out to far data segments, so my code broke.


					Lloyd Kremer
					Brooks Financial Systems
					{uunet,sun,...}!xanth!brooks!lloyd