Microsoft C 5.1 - bug

[Glenn L. Austin]

In article <1051 at dgbt.uucp> lew at dgbt.crc.dnd.ca (Lew Stelmach) writes:
>The following program compiles successfully on Microsoft C5.1,
>Microsoft Quick C 2.0, TurboC, DEC VAX Ultrix C, Sun Unix C, and other
>compilers.  However, it does not run correctly when compiled using
>Microsoft C5.1. Note that it runs correctly on Microsoft Quick C 2.0.
>
>The program allocates a ring of pointers. The  correct form of the
>output is shown below the program listing.  The actual values will
>differ from machine to machine . The pattern is what matters.  The
>critical feature to look for is that the right-most column of addresses
>(pointer values) should increase if the program runs correctly.  In
>MSC5.1 these numbers stay constant.  I compiled with the medium memory
>
>    [Example deleted]
>

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.


-----------------------------------------------------------------------------
| Glenn L. Austin             | The nice thing about standards is that      | 
| Apple Computer, Inc.        | there are so many of them to choose from.   | 
| Internet: austing at apple.com |       -Andrew S. Tanenbaum                  |
-----------------------------------------------------------------------------
| All opinions stated above are mine -- who else would want them?           |
-----------------------------------------------------------------------------