The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Volume 12 Issue 39

Monday 23 September 1991


o Carpal Tunnel Syndrome strikes
Peter Mellor
o Risks of technical translation
Bertrand Meyer
o Patent for Travelmation on Fare-Search System
Bob Frankston
o Rounding and truncating within multilevel software
Brenton Hoff
o Re: SunOS SPARC Integer Division Vulnerability
Dik T. Winter
o Re: Risks of mistreating programmers
Vesselin Vladimirov Bontchev
o Re: Play the lottery via Nintendo
Mike Cepek
o Re: documentation and the obsolete parts problem
o Ideas made simple
Bob Frankston
o Book review: Technological Risk, H.W. Lewis
Jack Goldberg
o Info on RISKS (comp.risks)

Carpal Tunnel Syndrome strikes

Peter Mellor <>
Mon, 23 Sep 91 12:10:21 BST
A friend of mine has suffered for years with what she thought was arthritis.
About 18 months ago, she was diagnosed as having a classic case of CTS. She
is due to have an operation to "depress the nerve in the wrist" very shortly
and is a bit concerned about the likely outcome. A few people she knows have
undergone the same operation with good results, but she has ben warned that
the scar will be extremely sensitive for a long time.

Does anyone out there have any experience, which I can quote to reassure or
warn her?

A have noticed a few curious things while this has been going on:-

 - All the people she knows who have suffered from CTS are female, and the
   affected hand has been the non-dominant hand. Is this a general rule?

 - The operation list at the consultant's surgery showed that he does around
   two CTS cases a week. That's one consultant in London, and only the cases
   severe enough to be operated on! How prevalent is CTS? Any statistics?

 - My friend is a highly-skilled touch typist (who for years trained other
   people to professional qualification standard), and very careful regarding
   the ergonomics of typing, position of seat, hands, etc. Why does CTS strike
   the professional, and not the idiot amateur like me, who types with one
   hand only (having lost the use of the other years back in a road accident),
   and whose idea of ergonomics is having the ash-tray and the coffee cup
   within easy reach? (I put in sufficient hours at a workstation
   to qualify for the "at risk" category, though!)

All information gratefully received. (I am aware of the correspondence around
RISKS-10.12 from Andrea Frankel et al., and have already passed on that

Peter Mellor, Centre for Software Reliability, City University, Northampton
Sq.,London EC1V 0HB +44(0)71-253-4399 Ext. 4162/3/1 (JANET)


Risks of technical translation

Bertrand Meyer @ SOL <>
Thu, 19 Sep 91 12:07:27 +0200
Being interested in languages (both natural and artificial) I lent an ear to
the following story, heard from a participant to a seminar I recently taught in
Berlin.  I tried to get the details right, but this is all hearsay and I can
make no guarantee of accuracy.

It appears that the UCSD Fortran (?) compiler had a confusing option which
enabled programs to write to a ``device'' as well as to a Fortran ``unit''. In
particular, unit 6 is the standard output in Fortran; but writing to DEVICE 6
rather than UNIT 6 would erase the whole disk...

Such an event, disastrous as it was, could only occur as a result of some
combination of bad luck and carelessness - for people using the original

But according to my source the German translation used the word ``einheit'' as
a translation for ``device''. (Apparently the translator also rendered ``unit''
by ``einheit'', which is indeed appropriate; but I am not sure of this point.)

The result is obvious: in German-speaking countries an inordinate number of
people lost everything as a result of erroneous write-to-device operations...

Perhaps someone with first-hand experience can confirm or correct.

Bertrand Meyer  (temporarily:

                                      [In UNITy there is DEVICEiveness?  PGN]

Patent for Travelmation on Fare-Search System

20 Sep 1991 20:28 -0400
There is an article in the Sept 16th issue of Business Travel News.  To quote
one paragraph "The patent decision recognizes as unique Travelmation's system
for checking its own database of fares and flight availability and
automatically selecting low fares that conform to corporate travel
policies."  Later in the article, "Part of the patent also covers
Travelmation's Trip Planner system, a program that allows travelers to send
their travel requirements from a personal computer to Travelmation..."

Rounding and truncating within multilevel software

behoffski <>
Sun, 22 Sep 1991 17:45 +0930
Rounding and truncating data can often get you into difficulties, as we found
recently in our fuel management system.

We collect data about refuelling transactions, and record the quantity of fuel
measured and the price of the transaction.  We report the quantity to the
nearest hundredth of a unit (litres), and the price to the nearest hundredth of
a dollar.  Recently, one of our customers complained that at a price of $1.00
per litre of fuel, the quantity would sometimes be 0.01 higher than the price.

What we found was that the program in the system that collected the
transactions and forwarded them to the database handled the numbers
differently: quantities were rounded to 2 decimal places, but prices were
rounded to 3 decimal places (effectively tenths of a cent).  The program which
brought these transactions into the main reporting database then truncated the
price to two decimal places.  I believe that this truncation was unintentional.

Our options in fixing this problem were:
    1. Rounding the 3-decimal digit price to 2 decimal places.
    2. Storing all 3 decimal places of the price.
    3. Reporting the price to 2 decimals, instead of 3.

Option 1 was quickly discarded: you must not round a number twice, as
distortions creep in (0.4449 -> 0.445 -> 0.45 instead of 0.44).

Option 2 was unacceptable: since every transaction report only reported
2 decimal places, the totals might be corrupted where they were computed
using the unrounded price instead of the rounded display.

Option 3 was chosen, so that the precision of the raw data agrees with the
precision for individual transactions shown on reports.  Given the accuracy of
the fuel measuring equipment, the thousandths of a cent was mostly garbage.

Just a small reminder of the hazards of truncation, rounding and significant

Brenton Hoff (behoffski)  | Senior Software Engineer | My opinions are mine | AWA Transponder          | (and they're weird).

Re: SunOS SPARC Integer Division Vulnerability

Dik T. Winter <>
21 Sep 91 01:00:03 GMT
OK, some sensible information from Barry Margolin <>:
 >           The patch replaces the C runtime library linked into the kernel;
 > we disassembled the old and new versions and compared them (actually, we
 > only disassembled the portion that implements the C integer division
 > operator, because of the description of the bug).

I intended to do that, but never came to doing it, although apparently I only
needed to look at the code presented in Version 7 of the Architecture manual on
page 183!

 > The change has to do with the action taken when division by 0 is detected.
 > In both cases, it does a "ta T_DIV0", i.e. signal a division-by-zero trap.

In the Architecture manual it says "te ST_DIV0", not a big difference.

 > The old code assumed that this instruction would never return; if it did,
 > it fell through to the rest of the code that implements division, and
 > presumably gets some wrong answer.  The new code is prepared for the trap
 > instruction to return, and the operator returns 0 in that case.

Yup.  In the first case, who are you if you return from the second trap?
And who are you when you return again?

 > Note that the description of the vulnerability is somewhat misleading.  The
 > perpetrator doesn't gain privileges by using division in his own program.
 > He somehow has to get the kernel to try to divide by zero; I suspect the
 > vulerability is that the kernel then might use the result as in array index
 > into some kernel structure (e.g. the u area).

No, not true.  With version 8 of the architecture Sun introduces instructions
for multiplication and division.  These are on non-version 8 machines trapped
as illegal instructions and emulated in software (since SunOS 4.0?).

 > As far as I'm concerned, the fact that the kernel ever even *tries* to
 > divide by zero is a bug.

True, but the reasoning is wrong.  Why is this code executed in kernel mode?
It ought to be executed in user mode.  The same holds by the way for a number
of fp emulation routines, plus some more.  The risk is that people
concentrating on getting there emulation code right are also bothered by
security issues.

The fix is completely bogus (although it serves as a kludge or hack).  When
something has to be done to support the user for which kernel mode is not
needed, the processor should go in user mode.  I think that Sun failed big
with its traps on unimplemented instructions.  Just try to single step under
adb an instruction that adb knows about but as does not; expect a panic.

dik t. winter, cwi, amsterdam, nederland            

Re: Risks of mistreating programmers (Welch, RISKS-12.36)

Mr. News <>
Thu, 19 Sep 91 09:25:15 +0200
Well, since probably I am the source of the information, permit me to add my
two cents worth. Yes, the above is mostly correct, althoug a bit scatchy. For
more information, see my paper "The Bulgarian and Soviet Virus Factories",
published in the proceedings of the First International Virus Bulletin
Conference on Computer Viruses, which was held in Jersey, UK, September 12-13.
A slight correction of your message - the town mentioned is Sofia (not Sophia)
and it is the capital of Bulgaria. :-) The BBS mentioned really exists, it is
called Virus eXchange, SysOp is Todor Todorov, and it is indeed specialized in
virus exchange and virus discussion between virus writers. I'm really sorry,
but this is not illegal in Bulgaria, so we really cannot stop them. :-((

Vesselin Vladimirov Bontchev         Universitaet Hamburg, FB Informatik - AGN   Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991:   Vogt-Koelln-Strasse 30, D-2000, Hamburg 54

Re: Play the lottery via Nintendo (RISKS-12.27)

"Mike Cepek, MGI" <>
Sun, 22 Sep 1991 11:16:23 CDT
In followup to the article I repeated here recently, George Anderson,
director of the Minnesota State Lottery, writes in the Sun 22 Sep 91
Minneapolis [MN] Star Tribune "Letters from readers", (pg 22A):

  [...] The play at home test will use Nintendo's control deck, a
  modem by which the deck communicates to the Lottery computer
  and a Lottery cartridge.  Transactions occur much as they do in
  the terminals found at our retailers across the state.  The
  cartridge will not be available through retail outlets.  No
  "children's games" are involved.  Only existing Lottery games
  will be available.

  Adults must preregister, predeposit (no credit play) and prove
  their age.  Adults will control a password for limited access.
  The deck will shut down if incorrect passwords are entered or
  if the machine is left unattended.  Daily play will be limited.
  Statements will be [mailed].

  [...] The control deck has enormous potential for interactive
  transactions -- it is used in Japan for personal banking and
  stock transactions.  Control Data Corp. and the Lottery believe
  that this test will demonstrate that the security and controls
  over player access removes the specter of minors' play, even as
  it provides the convenience demanded by Lottery players.

Oh, yes, lottery players here in Minnesota are quite near rioting at how
inconvenient it is to have to go to the nearest gas station or quick mart to

Seriously, I'd like to know more about how the Japanese use it.  Security
issues must have been adequately addressed for people to be comfortable playing
with their money via Nintendo.  Or maybe there aren't any hackers in Japan?

Re: documentation and the obsolete parts problem

Sat, 21 Sep 91 23:55:22 EDT
In RISKS-12.38, Stanley (S.T.H.) Chow <> comments on the
military's "obsolete parts" problem (the difficulty of obtaining obsolete
replacement parts for military systems).  He says:

>Given the well-known mountains of paper that the Pentagon requires for any
>hardware, and the many mil-spec's for documenting and testing any and
>everything, it is quite a surprise to me that anyone should need to reverse
>engineer anything. [...]
>Even excellent documentation is useless, Unless you can find it again.

I was peripherally involved in one effort to get around the obsolete parts
problem, and my impression is that the problem is NOT in finding the old
documents.  The problem is is that you can't rely on the documents.  They are
often out of date or incomplete.  There is always that one last minute design
change to fix the "final" (:-) bug, that may well not make its way into the
formal documents.  The basic problem is that there is no affordable way to
check whether the documents are correct, and without checking such documents
aren't much more reliable than an untested program.

Ideas made simple

21 Sep 1991 23:01 -0400
This is a copy of a letter I just FAXed to Business Week in response to their
article that presents object oriented programming as the grand solution to
all software problems.  This is absurd, but it is hard to blame Business Week
by itself when many within the industry espouse such views and some even
believe it.

As we've seen in some of the recent articles on representations many of the
fundamental difficulties aren't even related to programming as such.  As we
try to model the real world in our computer systems we are discovering what a
messy place it is.  But wouldn't it boring otherwise?

I apologize for the tone of this article, the moderator suggested that I be
stronger.  In appropriate circumstances I would much more forceful but I
think this letter represents the limit of what I can explain to a publication
like BW.  Feel free to send your own comments.  The fax number of "Readers
Report" (letters to the editor) is 212-512-4464.

To:     business week

From:   Bob Frankston
Date:    (09-21-91 22:49:19)
Subject:        Ideas made simple

At the risk of great oversimplification, I'll be extremely brief.  In doing
so, I appreciate your difficulty in covering complex issues of technology in
a small amount of space in a general (albeit business) publication.  Your two
recent articles, one on user interface and one on software development do a
disservice by announcing "solutions" to complex problems.

In your recent article on simplified controls for consumer appliance such as
VCRs you gloss over the fact that good (interface) engineering involve more
than just limiting capabilities until products become trivial to use.  While
this is indeed a valid and often appropriate technique, the problem faced by
product engineers is presenting the user with access to advanced capabilities
in a way that makes them obvious without being trivial.

In a similar vein, the problems of developing software are not suddenly
solved by the use of "objects".  Like structured programming, modular
programming, programmer teams, databases, relation databases, automatic
programming (now called programming languages), object-oriented programming
is yet another useful tool.  But it doesn't magically solve all problems.  In
fact, some of the capabilities described in the article are more the result
of taking advantage of the additional power of today's computer systems than
completely new techniques.  Many of the traditional programming techniques
represent engineering tradeoffs given the limited slack available and not
just ignorance.  With more powerful systems, more attention can indeed be
played to assembling components rather than crafting each one.

But we still have much to learn about what the components should be and how
they can fit together.  As you pointed out in this article, to some degree
the task is one of finding programming analogues to real world complexity.
If we indeed reflect the complexity of the real world, why should it suddenly
become simpler when it is modelled in a computer?

In other articles Business Week has explained that "reengineering", or the
process of rethinking a system as a whole, is much more effective than naive
modelling.  In contrast, the Software Made Simple article advocates mimicking
existing systems.

I do sympathize with the difficulties of presenting ideas concisely and
understandably.  In writing this letter I too have had to resort to extreme
simplification. The price is a loss of accuracy. But simplifying shouldn't
mean misleading the reader by suggesting that we have a grand solution to an
intrinsically complex problem.

Personal Categories:
Use Inner Header:
Delivery Priority:      High
Delivery Report:        Basic
Receipt Report:

Sender phone number:    617-945-9199 (Personal Pager)
Sender fax number:      617-244-1567
Cover Text for Faxes:
Cover Page for Faxes:

CANCEL: Ideas made simple

22 Sep 1991 10:55 -0400
You think BW shuts off its FAX machine on weekend or do they just get
overwhelmed after a particular stupid cover story?

To:     Bob Frankston|   EMS: Slate Corporation|   MBX: Bob Frankston
From:   MCI Mail Fax Service|   EMS: MCI Mail|   MBX: POSTMASTER @ mci @
Date:   09-22-91 03:10:00 (09-22-91 03:39:37)
Subject:        CANCEL: Ideas made simple

Your fax message

       To:                   Readers Report
       Destination Fax:      212-512-4464
       Date/Time Sent:       Sun Sep 22, 1991  3:02 am  GMT
       Message ID:           24910922030242/0004464426NC4EM

was not delivered.

       Date/Time Cancelled:  Sun Sep 22, 1991  7:10 am  GMT
       Delivery Attempts:    12
       Cancellation Code:    0015 - Ring no answer

For online assistance type HELP FAX CANCEL or contact MCI Mail
Customer Support at 800-444-6245 (U.S. only) or 202-833-8484.

Please retain the information contained in this cancellation
when calling for assistance.

Book review for risks

Jack Goldberg <>
Mon, 23 Sep 91 13:48:35 -0700
I found the book "Technological Risk" by H.W. Lewis, W.W. Norton & Co., 1990,
to be a very thoughtful and readable introduction to risk assessment.  Lewis is
a professor of physics at UC Santa Barbara and has chaired numerous government
risk assessment committees.  The dust cover has high and accurate praise from
Hans Mark (former deputy administrator of NASA), W.H. Press (professor of
Astronomy and Physics at Harvard) and James Schlesinger (former Secy of Defense
and Secy of Energy).  The first section, Generalities, talks about the risks
and value of life, the measurement, perception, politics, assessment and
management of risks, and "The delusion of Conservatism".  The second section,
Specifics, gives examples from toxic chemicals, chemical carcinogenesis,
highway safety, air transportation, ionizing radiation, fossil fuels, nuclear
winter and non-ionizing radiation.  There is no major discussion of computer
risks, but the subject is touched on in discussions of air transportation.
Lewis has lots of experience.  The book has much wisdom and is free of dogma.
It is also a pleasure to read.

Please report problems with the web pages to the maintainer