risks@csl.sri.com (RISKS Forum) (02/27/90)
RISKS-LIST: RISKS-FORUM Digest Monday 26 February 1990 Volume 9 : Issue 71
FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS
ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
Contents:
Journalists and computers: `Z' (R. Clayton)
Space Shuttle (Steve Bellovin)
Magellan spacecraft will need frequent guidance from Earth (David B. Benson)
More on Air India Airbus A320 (Steve Milunovic)
AT&T (Clifford Johnson, Rob Warnock, Steve Bellovin, David Paul Hoyt)
Re: Computerized Collect Calls (John (J.G.) Mainwaring)
A different multiple-copy problem (SEN) (Dan Craigen)
The RISKS Forum is moderated. Contributions should be relevant, sound, in good
taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome.
CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line
(otherwise they may be ignored). REQUESTS to RISKS-Request@CSL.SRI.COM.
TO FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR>
cd sys$user2:[risks]<CR>get risks-i.j . Vol summaries now in risks-i.0 (j=0)
----------------------------------------------------------------------
Date: Wed, 21 Feb 90 15:04:48 EST
From: clayton@thumper.bellcore.com (R. Clayton)
Subject: Journalists and computers: `Z'
Earlier this year, the New York Times published an anonymous op-ed piece about
Gorbachev's reforms. Since the piece was quite pessimistic, speculation arose
about the author's identity. The 19 February 1990 issue of The New Republic
has an article by Lionel Barber identifying the author as historian Martin
Malia at U. C. Berkeley. Among the reasons given for this choice was:
The hardest evidence, however, comes from Berkeley's own history
department. According to a staff member whom I interviewed, Malia
composed part of the Daedalus article [a longer version of the
op-ed piece] on a departmental computer under the filename "PERES" -
presumably a reference to perestroika, not the Israeli politician.
The staff member called up the file on his own computer during our
interview and read me lengthy passages, all of which were identical
to passages in "To the Stalin Mausoleum" [the title of the Daedalus
article].
A few pages further on in the same issue, Katie Hafner (who I believe
was causing a stir elsewhere on the network recently) has an article
on the Robert Morris trial. Her conclusion was that Morris'
conviction was a small step for some abstract principle, but had
little or no relevance to practical concerns about computer crime.
------------------------------
Date: Sun, 25 Feb 90 19:57:36 EST
From: smb@ulysses.att.com
Subject: Space Shuttle
Sunday's launch of the space shuttle was delayed because of problems with the
backup tracking computer used by the range safety officer. According to the
Air Force, the problem was ``bad software''. No word, at least in the stories
I've seen, about what the bug was, or about why it affected only the backup
computer -- or how long this bug has been present.
--Steve Bellovin
------------------------------
Date: Wed, 21 Feb 90 11:51:36 PST
From: dbenson@cs2.cs.WSU.EDU (David B. Benson)
Subject: Magellan spacecraft will need frequent guidance from Earth
Idahonian/The Daily News, Weekend, February 17 & 18, 1990
PASADENA, Calif. (AP) -- The Magellian spacecraft speeding toward cloud-shrouded
Venus on a $550 million mapping expedition, will need frequent commands
from Earth until NASA fixes a computer problem.
Despite the failure of a computer chip on the spaceship, "there's
no threat to the mission," said Edwin Sherry, a technical assistant at
the space agency's Jet Propulsion Laboratory.
Until engineers locate the faulty chip, they must send Magellan
new commands every other day to make sure it is pointing in the proper
direction, Sherry said.
He said a similar computer chip failure happened before Magellan
was launched and that such a failure is expected about once annually.
"You'd hope for zero faults like this," Sherry said. "But they're
typical of working with state-of-the-art equipment. It's remarkable we
have so few."
Magellan was launched from space shuttle Atlantis on May 4. It will
go into a polar orbit around Venus on Aug. 10.
[Two paragraphs about the mission deleted.]
The problem developed Sunday as the spacecraft got ready to take
a fix on two distant stars to make sure it was pointing the right way. An
error was detected in a tiny part of Magellan's computer memory.
The error prompted Magellan to shift to a backup computer and point
its solar panels toward the sun to increase the power supply.
The failure was apparently the result of electrical corrosion at a
junction between two types of material on a single memory chip, leaving the
chip unable to remember anything, Sherry said.
He said, however, engineers haven't yet ruled out the possibility
that the chip was damaged by an electrically charged particle spewed out
by the sun, which is near the peak of its 11-year cycle of activity.
Magellan uses gyroscopes to sense when pressure from solar wind
makes the spacecraft drift slightly, or point in the wrong direction. The
gyroscopes normally issure automatic commands to three spinning wheels,
which correct the spacecraft's alignment.
Magellan's main computer is programmed to take a fix on the two
stars each day to determine the spacecraft's actual allignment. If this
"star calibration" shows the gyroscopes failed to align Magellan correctly,
they again command the wheels to adjust the craft's position.
[Oh well, its only an AP staff reporter...]
[I recall that there is also some computer problem with Galileo, maybe
from an article in AAAS Science, but I haven't seen it on RISKS.]
------------------------------
Date: Mon, 26 Feb 1990 13:23:04 PST
From: Steve Milunovic <Steve_Milunovic@quikmail.sri.com>
Subject: More on Air India Airbus A320
Crash in India Rekindles Dispute over Safety of Airbus A320 Jet
(Steven Greenhouse, c.1990 N.Y. Times News Service, BRIEF EXCERPT)
PARIS. The crash of an Airbus A320 jet that killed 97 people in India last
week has reignited a dispute in France over whether the computerized, highly
advanced aircraft is too complicated to fly. The French pilots union is urging
the airliner be grounded in France. ``This plane is sometimes put into
operation by people who aren't qualified enough,'' said Jean-Claude Bidot,
secretary general of the French Airline Pilots Union. ``It's a supercomplicated
aircraft.''
But the maker of the plane, the four-nation consortium known as Airbus
Industrie, said the plane was quite safe and the French pilots were opposing it
to protect their economic interests. The plane uses two pilots; many other
aircraft use three. [...]
------------------------------
Date: Fri, 23 Feb 90 16:15:41 PST
From: "Clifford Johnson" <GA.CJJ@Forsythe.Stanford.EDU>
Subject: AT&T (Kamens, RISKS-9.69)
> "do . . . while" construct, which contained a "switch" statement, which
This presumes that the error was made by one particular programmer. But such
production code is surely the responsibility of a team of programmers, each
module being evaluated by more than one peer and supervisor. All programmers
make errors. The problem is why this "stupid programming error" survived
through to production. Correcting the code does not correct this root problem;
and the root problem, failure to catch the error, may be less likely in other
languages.
> if we can't expect our programmers to understand the language
> with which they are programming, then what *can* we expect?
Certainly, we must expect programmers to make such mistakes whatever their
launguage, and however well they understand it. Some languages do assist
error-catching more than others, APL being the extreme worst case, for example.
------------------------------
Date: Fri, 23 Feb 90 22:35:06 PST
From: rpw3%rigden.wpd@sgi.com (Rob Warnock)
Subject: Re: Problems/risks due to programming language, ... (RISKS-9.69,.70)
The BLISS family of languages originally had this hazardous multi-level break,
"EXIT[n]", but then they added (*sigh*) a better scheme. Any expression (and in
BLISS, *all* control structures such as begin/end, if/then, case, for/while
loops, etc, were expressions and could yield values) could have a label
attached, and from anywhere within that expression only you could say, "LEAVE
<label>" or "LEAVE <label> WITH <value>". That way, the thing being left stayed
constant even if you added or removed interior levels. Further, labels had to
be declared before being used (generally considered a pain, until the day it
saved you from a mispelling), and a label could be used -- attached to
something -- only once in the scope of its declaration. (Of course, you could
have many LEAVE's inside a labelled structure.) Outline:
LABEL FOO;
LOCAL X;
<other decl's>...
...
X = FOO: WHILE (not_done)
DO
...
IF (condition)
LEAVE FOO WITH 47;
...
OD; ! yes, BLISS used CASE/ESAC, IF/FI, &c.
The default value for a loop which exits "normally" is -1.
In my experience, the labels+LEAVE construct gave *much* more reliable code
than C's "break", or BLISS's old EXIT[<num>], or the like, while still avoiding
GOTOs. (And being able to deliver a value made writing common search loops
easy.)
-Rob
Rob Warnock, MS-9U/510, Silicon Graphics, Inc., 2011 N. Shoreline Blvd.
Mountain View, CA 94039-7311 (415)335-1673
------------------------------
Date: Sat, 24 Feb 90 02:01:52 EST
From: smb@ulysses.att.com
Subject: C problems?
There is little point to enumerating the vulerabilities of C; one could write a
book about them. In fact, Andy Koenig already has: ``C Traps and Pitfalls'',
which I recommend to anyone using the language. That is not the point,
however. The real question is whether or not any real language is sufficiently
free of such traps as to significantly reduce the probability of errors.
To tremendously oversimplify the situation, languages that are higher-level
than C often achieve their power at the price of complexity. This complexity
itself can can breed errors; see, for example, Hoare's comments on Ada, or
Koenig's early paper ``PL/I Traps and Pitfalls''. To be sure, the power can
help avoid some bugs -- the ``fingerd'' bug that the Internet
virus/worm/parasite exploited could not have happened in PL/I because strings,
and in particular variable-length strings, are a built-in data type; one would
not have C's temptation to use fixed-size arrays.
On the other hand, languages that are ``safer'' than C often achieve their
safety by significantly restricting their expressive power. This can have
several results. First, the programmer must concentrate more on low-level
details again, with the concommitant pressure towards short cuts (i.e., fixed
length arrays -- Pascal, for example, does not even have malloc()). Second,
the language may become unsuitable for large projects; again, Pascal comes to
mind. Third, programmers will cheat -- move around the boundaries of the
language using escape hatches or arcange knowledge.
It may be that there is a suitable compromise. There have certainly been
enough attempts; what is missing is convincing evidence that these actually
reduce the error rate in real life. Note that by ``real life'', I specifically
include the lifetime history of real programs -- and that includes
modifications and changes over the years by many different people. I assume
that there have been some attempts to measure this; I wouldd appreciate
citations.
The other approach often taken is to design languages that are in some sense
``suitable for verification''. That is, features are inserted or omitted not
simply because of their complexity or aesthetics, but also because of their
effect on attempts to verify the program using formal methods. Apart from the
aforementioned question of whether or not such languages are really suitable
for real programming problems, they do nothing in and of themselves to reduce
the error rate; they merely make it easier for a competent, well-trained
programmer with enough time to validate a program as its being written. (Some
would claim that writing a program using formal methods will result in
less-buggy programs. I will not dispute that here, except to note that that
requires more time up front -- and we all know how feasible that can be when on
a tight schedule, even if it seems likely to reduce total project time later
on.)
If such languages help, though, we are very far from our original ideal, which
was a technical solution to the problem. Verifying programs, or constructing
them using formal methods, requires rather different, and arguably scarcer,
skills than are present in the programming population today. It is thus a
people problem, and an educational one. In fact, it is far from clear that
this will accomplish very much overall except to recast the obvious: that
better programmers write better programs. Wasn't it Knuth who demonstrated
years ago that the best programmers produced code that was 4-5x faster *and*
4-5x smaller than the worst?
Our goal must be to let anyone write better programs. The challenge is not
only devising the methods, but also demonstrating that they work.
--Steve Bellovin
------------------------------
Date: Sat, 24 Feb 90 12:24 CST
From: david paul hoyt <YZE6041@vx.acs.umn.edu>
Subject: RE: AT&T (Smith, RISKS-9.70)
> If the AT&T programmer had coded "goto" instead of "break", ...
The reason the programmer would have had problems with his/her peers is that
(unconstrained) goto's greatly reduce the maintainability of the code.
Ultimately increasing the likelihood of failure. In my experience, it has been
very rare that with a little more thought, I couldn't come up with a solution
that got rid of the need of a goto. Non-local goto's are almost always a sign
of unwarranted complexity and that the design should be rethought. By
the way, I am experienced in large scale complexity. I have developed,
maintained and converted +million line programs.
david | dhoyt@vx.acs.umn.edu | dhoyt@umnacvx.bitnet
------------------------------
Date: Fri, 23 Feb 90 16:20:00 EST
From: John (J.G.) Mainwaring <CRM312A@BNR.CA>
Subject: re: Computerized Collect Calls
Mark Brader's posting in RISKS-9.69 about the reporter who reached the editor
who said "... computer telemarketing things" just goes to illustrate one of the
pervasive threads of this forum: Computer Aided Stupidity will have far more
impact on society than Computer Aided Intelligence for years to come. Mark's
reporter and editor seem to be cases in point.
Automated systems such as this have easy mechanisms to allow the user to talk
to a live operator when the automated system doesn't meet their needs. It does
have to occur to one or other of the users (in this case the reporter) that the
live operator would be a good idea. Automation is brought about because of
consumer pressure brought on the PUCs which control the telephone operating
companies' rates. If you would really prefer an all manual system, perhaps
next time your PUC is considering a rate application from your telephone
company, you will go along and tell them you don't think the phone company is
asking for enough. By and large, this is an uncommon occurrence.
Perhaps we could all entertain ourselves with stories about how when you call
with these new fangled rotary dial phones, they don't even know that Millie is
always next door at Dottie's having coffee at this time of the morning like the
operator always knew. I doubt if there ever was or will be an innovation
involving something we all use every day that doesn't let someone come up with
a story to convince himself he's (marginally) smarter than some machine. Once
the new becomes familiar we usually really do end up in control of the
machines.
------------------------------
Date: Sat, 24 Feb 90 00:19:57 EST
From: dan@ora.on.ca (Dan Craigen)
Subject: A different multiple-copy problem (SEN)
Unfortunately, we're all used to receiving multiple copies of the Risks digest
from time to time. However, when I got home today, I found twelve copies of
Software Engineering Notes at my front door. Apparently, somewhere along the
distribution line, the twelve copies were bundled together with my name and
address at the top. The other eleven are for various individuals spread out
through Ontario. The ordering of the journals is based on ACM membership
number.
An interesting Risks twist. I'll put the other eleven back in the postal system
tomorrow.
------------------------------
End of RISKS-FORUM Digest 9.71
************************