ctrl+c and destructors

[H. S. Teoh]

On Thu, Oct 03, 2013 at 05:04:02PM -0700, Walter Bright wrote:
> On 10/3/2013 4:49 PM, Jonathan M Davis wrote:
> >Just because it won't kill anyone doesn't mean that it's okay for it
> >to continue after it's in a bad state. It could do other nasty things
> >to the system (including corrupt the files that it's operating on).
> >Once a program's in an invalid state, all bets are off. I fully
> >concur with Walter that it's better to kill the program at that point
> >and restart it whether lives are on the line or not. And if that
> >means that the user sees crashes, oh well.  They'll complain and the
> >developer will have to fix them, which is exactly what they need to
> >do, because they wouldn't be getting stuff like segfaults or Errors
> >if their code wasn't broken.
> 
> Exactly.
> 
> Note that memory corruption can also result in corruption of user
> data, as I mentioned, and it can ALSO result in corruption of your
> system. The music player can read and write files, right? Kaboom.
> 
> I was just talking to Andrei earlier about the bad old MSDOS
> programming days. There, if you had an errant pointer, it didn't seg
> fault. It would scramble the operating system tables, and having
> 
>     YOUR HARD DISK SCRAMBLED
> 
> was a not uncommon experience.

Ah yes, those were the days when you *always* kept a full backup of a
fully-working snapshot of your OS and dev environment on a separate
floppy, so that when your program inevitably crashed / destroyed the OS,
you could power off and reboot from the good copy (and promptly make
another copy thereafter, in order to not also destroy the last good
disk!). Hitting reset / power cycling several times an hour was pretty
common, since the most trivial of bugs easily caused the system to hang,
or get stuck in graphics mode with no way to (easily) switch it back, or
lock up the keyboard somehow, or do any number of other erratic things.

Write to a wrong memory address (e.g., dereference a wrong pointer), and
boom, you just broke DOS in a subtle way that only shows up the next
time you write to a file. Write to another wrong memory address, and
boom, one of DOS's core routines got overwritten, now disk I/O doesn't
work, or DOS just hangs and won't respond to anything. Jump to an
invalid func ptr with the wrong value, and boom, you just entered the
DOS FORMAT routine. Bye bye sweet data, it was nice knowing you.


> Continuing program execution after it failed due to programming bugs
> is just a bad, bad, bad idea, and it needs to die.

Heh, my Perl script actually picked a vaguely relevant signature line on
its own this time, without manual intervention. :-P


T

-- 
If you want to solve a problem, you need to address its root cause, not
just its symptoms. Otherwise it's like treating cancer with Tylenol...