Xref: utzoo comp.lang.c:7268 comp.sys.ibm.pc:11854
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!pasteur!ucbvax!decvax!decwrl!sun!plx!slvblc!dick
From: dick@slvblc.UUCP (Dick Flanagan)
Newsgroups: comp.lang.c,comp.sys.ibm.pc
Subject: Re: MSC Danger (was Re: Turbo C vs Quick C)
Summary: Be careful out there!
Message-ID: <492@slvblc.UUCP>
Date: 14 Feb 88 15:31:52 GMT
References: <389@lscvax.UUCP> <567@naucse.UUCP> <2946@dasys1.UUCP> <5441@cit-vax.Caltech.Edu>
Sender: uupc@slvblc.UUCP
Reply-To: slvblc!dick@ucscc.UCSC.EDU (Dick Flanagan)
Organization: SLV Systems Group, Ben Lomond, CA
Lines: 29
Disclaimer: none

In article <5441@cit-vax.Caltech.Edu> tim@cit-vax.Caltech.Edu (Timothy L. Kay) writes:
>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.
>
>This can happen with *any* C compiler that uses the large model. . . .
>If you break the rules and link large model with small model, who knows
>what is going to happen? . . .
>
>The only solution is to stick to small models or get some memory protection
     ^^^^

An alternative solution is to simply be careful and not break the rules.
DOS has always been very unforgiving in this area (it's as much a victim
of the Intel architecture as we are), and blaming any compiler because it
"lets" us screw up is a bit tacky.  (Flame != Tim)

Dick

--
Dick Flanagan, W6OLD                         GEnie: FLANAGAN
UUCP: ...!ucbvax!ucscc!slvblc!dick           Voice: +1 408 336 3481
INTERNET: slvblc!dick@ucscc.UCSC.EDU         LORAN: N037 05.5 W122 05.2
USPO: PO Box 155, Ben Lomond, CA 95005