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 6: Issue 14

Monday, 25 January 1988


o Safe programming languages
Bob Estell
o More about the technology transfer policy
Paul Smee
o A second Sun clock error: no sanity checking
John Bruner
o "Things That Go 'Beep'"
Paul Fuqua
o High-voltages and Europe vs USA
Kee Hinckley
o I know why Ham Radio Operators die so often!!! (silly)
Eric Townsend
o Info on RISKS (comp.risks)

Safe programming languages

"CL351::ESTELL" <>
25 Jan 88 07:50:00 PDT
About a decade ago, Lawrence Flon gave us the following axiom:

 "There never has been, nor will there ever be, any programming language
  in which it is the least bit difficult to write bad code."


John Pershing <>
25 Jan 88 11:41:42 EST
You can't even necessarily write the null program without encountering

There is an apocryphal story about the large number of attempts that were
required in order to produce a "correct" version of MVS's null program,
IEFBR14 (this was done back in the days when MVS was still called OS).
As with all MVS programs, IEFBR14 is called using the standard system
calling conventions, and all it has to do is return successfully.

The first version was something like this:

         IEFBR14 START
                 BR    14       Return addr in R14 -- branch at it

First bug:  A program indicates its successful completion by zeroing
register 15 before returning; this version of the null program "failed"
every time.  Try it again:

         IEFBR14 START
                 SR    15,15    Zero out register 15
                 BR    14       Return addr in R14 -- branch at it

Much better.  However, this caused some-or-other problems with the linkage
editor, since the END statement didn't specify the primary entry point
of the routine.  Version three:

         IEFBR14 START
                 SR    15,15    Zero out register 15
                 BR    14       Return addr in R14 -- branch at it
                 END   IEFBR14

At least now, the null program was functionally correct.  However, dump
analysis was impeded because the program didn't include its own name in
the source code, as an "eyecatcher" (this is a time-honored convention).
Null program, mark four:

         IEFBR14 START
                 USING IEFBR14,15  Establish addressability
                 BR    GO          Skip over our name
                 DC    AL1(L'ID)   Length of name
         ID      DC    C'IEFBR14'  Name itself
                 DS    0H          Force alignment
         GO      SR    15,15       Zero out register 15
                 BR    14          Return addr in R14 -- branch at it
                 END   IEFBR14

The next change had something esoteric to do with save-area chaining
conventions -- again, for the sake of conventions and to keep the dump
analysis tools happy.

Note that the "null program" has tripled in size:  both in terms of the
number of source statements and in terms of the number of instructions


More about the technology transfer policy

Paul Smee <Smee@AUCC.AC.UK>
Mon, 25 Jan 88 11:47 GMT
Perhaps one of the lesser-known 'features' of the US technology transfer policy
is the fact that the US government applies it internationally.  For example:

If a British firm manufactures, say, a PC-XT clone, even using 100% British
components (not likely, I'd admit, but for the sake of argument), and then
sells it to one of the proscribed countries, the British manufacturer is deemed
to have violated the US law.  This despite the fact that no British law may
have been broken.  The manufacturer is now liable to be arrested and prosecuted
if he ever visits the US in the future.  Further, in some cases, the US
government will put pressure on the British government which leads the British
government to 'blackball' the manufacturer.  Several small UK companies have
been driven under in just this way.  Now, according to last week's news
reports, the US is trying to convince the British government to extend the
extradition treaties so that these people could be extradited to the US for

The record of the British government in protecting its nationals in this sort
of case is appalling; typically, they will even refuse to assist in preparation
of an appeal against the US trade restriction.  So, I see every reason to fear
that they will give in to this latest idea.  And remember, the British
nationals involved can end up in this situation without doing anything illegal
under British law.  The attitude of the British government appears to be summed
up as 'well, the Americans are our friends, and we wouldn't want to offend
them'.  (Of course, we've got a different outlook on it when the other guys
impose such conditions on their 'friends'.)

There are other side effects of this US legislation.  The University of London
had a great deal of trouble getting their second Cray (despite the fact that
they had one).  The Cray was already in-country; they were buying it pre-owned
from one of the national laboratories.  The problem?  The US Department of
Commerce wanted them to sign a statement guaranteeing that only UK and US
national students and staff would be allowed to use it.  (I'm not sure what
conclusion was finally reached, but they did eventually get the machine.)  More
recently, DEC pulled out of negotiations for selling a mainframe to one of the
Scottish Universities, for similar reasons.

Can this be sensible, I ask myself.  Just for clarification, let me add that I
am a US citizen, though resident over here.  I think (and hope) that I (still)
have the right to argue against what I see as misguided policies of my
country's government.

The risk?  Well, as I see it, a very great risk that in defending us against
the enemy, the government will become as great an oppressor of freedom as (they
say) the other guys are.

Paul Smee, Senior Systems Programmer, University of Bristol
     at AUCC.AC.UC  iff you can find an ARPA host doing domain addressing,
                    and which does not route thru UCL
 pes!bath63!ukc!mcvax!...  on USENET (if you're lucky)


A second Sun clock error: no sanity checking

John Bruner <>
Sun, 17 Jan 88 18:53:39 PST
The recent incident with the Sun leap-year clock problem illustrates
a RISK which noone has mentioned yet: software which blindly trusts
hardware without performing sanity checks on the data received therefrom.

There were two coding errors in the Sun clock code.  The first was the
use of a side effect in a macro argument, which caused the hardware
time of day register (TODR) to be loaded with garbage.  The second error
was the use of the contents of the TODR without any range checking.

Classically, the time in UNIX has been maintained by software in
response to interrupts from an interrupt source (line clock or
programmable timer).  This is true on the Sun as well, except that
every 30 seconds the Sun kernel also compares the software-maintained
time to the contents of the hardware TODR.  If the two values differ,
provisions are made to synchronize the software-maintained time to the
hardware TODR.  The apparent assumption here is that the TODR will be
more accurate, and usually that assumption is justified.

The system call "settimeofday" changes both the software-maintained time and
the TODR.  When the unfortunate leap-year bug manifested itself,
"settimeofday" correctly changed the software-maintained time but trashed
the TODR.  Within 30 seconds the kernel detected that the two values were
different and starting trying to "correct" the software-maintained time to
match the garbage in the TODR.  A simple range check applied to the
difference between these two values could have detected that the TODR was
trashed and suppressed this "feature."

  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)                 (415) 423-4848


"Things That Go 'Beep'"

Paul Fuqua <>
Mon, 25 Jan 88 14:57:38 CST
     To add another element to the discussion about risks related to normal
house wiring, the Dallas Morning News on Jan 24 printed an article about an
electric-company experiment in remote meter reading.
     Their system broadcasts a "coded electrical signal" at 12500 Hz on top
of the normal 60 Hz power to 5000 customers in the test area.  About 1000
participants have a special meter that responds to the signal by reporting
usage or, if so equipped, by turning off major appliances like air
conditioners, water heaters, or furnaces.
     The article contains all sorts of glowing comments from the utility
about cost savings and other uses for the equipment (fire alarms, for
example).  The focus of the article, though, is on one family that, although
not participating in the experiment, can *hear* the signal as an intermittent
one-second beep, and it's driving them crazy.

     RISKS relevance:  First, it's a computerised system, and we all know
what hazards there are -- I, for one, don't want my heating and cooling
subject to the utility's direct orders.
     Second, around 0.5% of customers in test areas around the country have
complained about the noises.  Westinghouse (the manufacturer) is considering
increasing the signal frequency to 19000 Hz.  Will it then annoy dogs or
     In closing, a quote from the article:

Despite assurances that the signals won't harm electronic equipment, he [John
Feagins, a member of the affected family and a college physics student at UT]
said he wants the signal removed to protect his computer.

"To me, that's like putting something in the water," Feagins said.  "I want
pure, clean electricity for all my electronic equipment."

Paul Fuqua, Texas Instruments Computer Science Center, Dallas, Texas
CSNet: or pf@ti-csl
UUCP:   {smu, texsun, im4u, rice}!ti-csl!pf


High-voltages and Europe vs USA

Kee Hinckley <apollo!nazgul@EDDIE.MIT.EDU>
Tue, 12 Jan 88 19:02:46 EST
The European argument is clearly out, not only are most European currents not
DC, most of them are running more than 110.  However I have heard concerns
about this recently but I don't remember where.  In fact one of the issues
I've read about concerns electric blankets.  The article claimed that there
were statistically significant increases in the number of miscarriages from
women who slept under electric blankets.  On the level of risk from standard
household current there's an obvious testing problem.  Namely it's probably
impossible to find any place where there isn't any current interference and
yet all other factors remain equal.  Obviously if you live in a house without
electricity there are bound to be other factors effecting your health.  It
seems to me that you'd have to do a very long blind study involving new
houses, some built with heavy shielding, some without.
                                                              Kee Hinckley

### {mit-erl,yale,uw-beaver}!apollo!nazgul ###   (Apple ][e ProLine BBS)    ###
###      apollo!       ###    nazgul@pro-angmar.uucp    ###
###           nazgul@apollo.uucp           ### (617) 641-3722 300/1200/2400 ###


I know why Ham Radio Operators die so often!!! (silly)

eric townsend <flatline!erict@uunet.UU.NET>
11 Jan 88 02:30:55 GMT
It has nothing to do with non-ionizing radiation or with building their
own equipment and the things they get exposed to.

It's very, very simple:  Have you ever watched what a Ham Op *eats*????
Yech. :-) :-)

J. Eric Townsend ->uunet!nuchat!flatline!erict smail:511Parker#2,Hstn,Tx,77007

Report problems with the web pages to the maintainer