Xref: utzoo comp.lang.c:7329 comp.sys.ibm.pc:11985
Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!tim
From: tim@cit-vax.Caltech.Edu (Timothy L. Kay)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: MSC Danger (was Re: Turbo C vs Quick C)
Message-ID: <5441@cit-vax.Caltech.Edu>
Date: 14 Feb 88 20:50:49 GMT
References: <389@lscvax.UUCP> <567@naucse.UUCP> <2946@dasys1.UUCP>
Reply-To: tim@cit-vax.UUCP (Timothy L. Kay)
Organization: California Institute of Technology
Lines: 23
Keywords: good better best

In article <2946@dasys1.UUCP> wfp@dasys1.UUCP (William Phillips) writes:
>In article <567@naucse.UUCP>, wew@naucse.UUCP (Bill Wilson) writes:
>> Turbo C is superior to Quick C.  On our campus here we have also
>> had Quick C blow away hard drives, so be careful.
>
>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

This can happen with *any* C compiler that uses the large model.  Once
you allow the compiler to generate code that messes with the segment
registers, you open yourself up for much more destructive bugs.  If you
break the rules and link large model with small model, who knows what
is going to happen?  Suppose the result is that your bug scribbles all
over low memory, exactly where some sectors from the FAT happens to
be.  Then the program bombs.  Your next disk write will scribble in
random places on the disk because the in-core copy of the FAT sectors
has been clobbered.

The only solution is to stick to small models or get some memory protection
ala Unix/386.

Tim