NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/c/12402

Internet Message Format | 1992-08-16 | 5.7 KB

Xref: sparky comp.lang.c:12402 comp.programming:2347
Newsgroups: comp.lang.c,comp.programming
Path: sparky!uunet!gatech!bloom-beacon!bloom-picayune.mit.edu!news
From: [e-mail] (Steve Summit)
Subject: Re: Allocate memory to typed in string, How?
Message-ID: <[e-mail]>
Sender: [e-mail] (News system)
Nntp-Posting-Host: adam.mit.edu
Organization: none, at the moment
References: <[e-mail]> <[e-mail]>
Date: Sun, 16 Aug 1992 21:16:44 GMT
Lines: 97

In the context of assuming and/or imposing a limit on input line
length, and in particular with respect to doing so on the basis
of a restriction known to exist in the keyboard input subsystem
of the computer being used, here's a fascinating little tidbit
from the RISKS digest (aka comp.risks):

RISKS-LIST: RISKS-FORUM Digest  Wednesday 12 August 1992  Volume 13 : Issue 72

------------------------------

Date: Tue, 11 Aug 92 14:56:31 MDT
From: [e-mail] (Joseph F. Hull)
Subject: Re: Stupid things people do

I was working as a programmer for a military command center, the kind with
large screens around the walls which display current status of whatever.  The
system was a custom job with custom software, but was fairly stable (no
outstanding software problem reports, no recent modifications).  Normal
operations 24 hours / day, 7 days / week.

One Monday morning about 0600, the system crashed.  No problem.  The operator
initiated warm start on the hot backup system and dump procedures on the failed
machine; back on-line in less than 3 minutes (and called me, midnight shift
programming support).  A few minutes later the alternate system crashed.  What
to do?  (The dump takes about 11 minutes.  If we abort the dump to get on-line
as fast as possible, we lose any chance of finding out why the first crash
occurred.  And the primary system may go down again if we have an unrepaired
hardware problem.  But since both systems crashed within minutes of each other,
its probably a software problem, so if I don't get the dump, we have ZERO
chance of finding out what happened.)  Call the command post for permission to
complete the dump.  Denied.  Abort the dump.  Reboot the primary.  Initiate
dump on the alternate.  The primary crashes again.  Reboot the alternate.
Initiate dump on the primary.  The alternate crashes again.  This time we get
permission to allow the dumps to complete.  Reboot and back on-line.  By now,
it's after 0700.

Start analyzing what happened.  Trace the problem to a data input routine.
Hmmmmm. Seems like its overrunning the buffer and trashing an adjacent data
structure.  Can't be, the buffer is already larger than the physical limit on
the terminal (an IBM 2701 - a then modern but now ancient IBM Selectric
ball-type typewriter rigged as a computer input device).  Quick fix: move the
adjacent data structure further away from the buffer, re-assemble (Yes,
Virginia, we had computers before we had compilers.  What's that, you little
snot?  Yes, I did work on them and no it was not before Christ.), bring the
alternate to "hot backup" status and do a switchover.  Take a deep breath and
start figuring out WHY it happened, because the General has missed his Monday
morning briefing and is going to want to know whether he cna count on his
primary command and control system or not.

Hit a stone wall.  Couldn't find anything wrong with the code.  So I put an
alarm in that input routine, took my chewing out and went on with life.  Two
weeks later, my alarm went off.  The system didn't crash because I had moved
that fragile data structure, but it would have if I hadn't moved it.  The alarm
also triggered an on-line dump and, when I checked it, sure enough, that same
terminal had overrun its buffer again.  But it can't!  The buffer is 128
characters deep and the IBM 2701 is only 85 characters wide; you HAVE to enter
a carriage return to continue.

Well, not quite.  I finally made the connection between one particular Major
inputting data for the General's morning briefing and the alarms.  It seems
this Major had figured out that the display screens could handle lines 132
characters long even though the input devices could only provide 85.  So when
he got to the end of a line on the terminal, he would grab the typewriter ball,
drag it to the left, manually roll the paper forward and keep typing.  As long
as he was entering less than 128 characters, everything was ok.  But when he
went over that, ...

OBSERVATION 1:  A user will do anything (s)he can think of to get the job done.
OBSERVATION 2:  They are usually more creative than we are, i.e., they think of
                things we don't.

Jeff Hull, 1544 S. Vaughn Cir, Aurora, CO 80012  303-977-1061  [e-mail]

------------------------------

To Jeff's two observations we can of course add a few more:

OBSERVATION 3: Try not to depend on (i.e. make assumptions about)
things outside the part of the system over which you have control.
(In this case, the 2701 was well outside of the software module
in question.)

OBSERVATION 4: Rather than assuming that something will never
happen, guard against it.  In this case, don't assume that the
input can't be longer than 128 characters, but rather test that
it doesn't and in any case avoid overwriting that nonexistent
129th array element.  (Corollary: in C, use fgets rather than gets.)

OBSERVATION 5: Include run-time assertion checks to detect
failures of assumptions which can occur at run time.  (This
covers *all* assumptions, including those which under
observation 3 shouldn't have been made in the first place.
These run-time checks are obviously in addition to compile-time
checks to detect failures of compile-time assumptions.)

                    Steve Summit
                    [e-mail]