Xref: utzoo comp.unix.microport:3004 comp.unix.questions:12352
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.unix.microport,comp.unix.questions
Subject: Re: C bug causes double fault
Message-ID: <9900@smoke.BRL.MIL>
Date: 22 Mar 89 04:45:52 GMT
References: <244@tree.UUCP> <9884@smoke.BRL.MIL> <27245@cci632.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 17

In article <27245@cci632.UUCP> tvf@ccird7.UUCP (Tom Frauenhofer) writes:
>On Microport V/AT, what he wrote causes a kernel panic.  That doesn't seem
>to be reasonable behavior for an OS/library routine/whatever.

Of course nobody would call it "reasonable", but it's not too surprising.
Incorrect user-mode code on a nonprotected multitasking system (forced by
limitations of the PC/AT architecture) can easily crash the entire system.
For another example, when testing newly written DMD applications downloaded
into my (AT&T 5620 or 630) terminal, some bugs cause the whole terminal
to die and have to be rebooted.  That's just the nature of environments
without hardware memory protection.

To avoid problems in the original example, the C implementation would
have to perform many detailed checks at run time, which would be considered
prohibitively high overhead, or else the compilation environment would have
to detect *printf() format/argument type mismatches.  The latter is feasible
and perhaps by nagging the vendor it will be done in some future release.