MSC Danger (was Re: Turbo C vs Quick C)

[James R Vallino]

In article <2946 at dasys1.UUCP> wfp at dasys1.UUCP (William Phillips) writes:
>I know of a case where MSC (4.0 I think) utterly scrambled a hard drive
>(not backed up, natch), when a module compiled with one memory model was
>linked with modules compiled with a different model.  I've forgotten the
>exact details, but I saw what was left of the directories after the
>program was run -- total garbage.  So watch out for that one!
> 

To be somewhat fair to Microsoft, especially since the "exact details"
were forgotten, this type of thing can easily occur with ANY C program
which uses large data, that is segment:offset pointers.  You can get it
to happen even when you link the correct library. The problem is with
the hardware and operating system (or in this case the programmer) not
the compiler. A program running under MS-DOS can get to any memory location
in the 1 MByte memory space in which MS-DOS runs. This includes overwriting
critical sections of the operating system, such as the file allocation
table (FAT). Once this is trashed and a program does another write to disk
then you better hope that the Gods are on your side.

The situation which seemed to cause this most frequently was inexperienced C
programmers writing code which ended up using pointers which were NULL.  These
then read from low memory and got garbage other data which ended up trashing
the FAT.  My boss was not pleased when it was his system that got trashed the
first time this problem surfaced. So if you want to blame a compiler then
blame ALL the C compilers for not providing an option to check for use of
NULL pointers at runtime. (The MSC V5.0 compiler is the first C compiler I
have ever worked with which does have this option.)
-- 
Jim Vallino	Siemens Research and Technology Lab.,Princeton, NJ
CSNET: jrv at siemens.siemens-rtl.com
UUCP: {ihnp4,philabs,seismo}!princeton!siemens!jrv