Bugs

Found in alt.humor. Posted by: dcoble <dcoble@gateway.net>

1. Why Are You Being Sent This Message?
   
   This message is being sent to every software house in the country. It is about BUGS. And everyone needs to know the facts. It explains what BUGS are, how they spread, how serious the threat may be, and how they can be avoided. Because it has to deal with matters of software and hardware, you may find some of the information disturbing. But please make sure that everyone who needs this advice reads this message. The more people who know about BUGS the less likely they are to spread.
   
   So, if you employ programmers, think carefully about what they need to know. Whether or not you approve, many programmers do write programs, and some may experiment with assembler.
   
   Even if you think your programmer's don't act in this way, they will still need advice because they may have friends who encourage them to.
   
2. Why Should You Be Concerned About BUGS?
   
   Any computer user can suffer from BUGS, depending on their behaviour. It is not just a hacker's problem. There is no cure and they can cause crashes. By the time you have read this, probably 3000 computers will have crashed in this country. It is believed that a further 400,000 carry BUGS. This number is rising and will continue to rise unless we all take precautions.
   
3. What Are BUGS?
   
   BUGS are caused by logical errors. These can attack a program's validation routines which normally help fight off bad input and corruption. And if this happens then programs can develop BUGS. They become unreliable and crash from errors that cannot be detected.
   
4. How Do Programs Become Infected?
   
   Because errors can be present in specifications and designs, this means that for most programmers the only danger comes through using a faulty design. This applies to both top-down and bottom-up design. (It is believed that other forms of design are also risky, such as SSADM, particularly if specifications are taken at face value.)
   
   So the errors can be passed from design to design, design to program, and back again from program to design. For those who use assembler there is an added risk from sharing software interrupts or device printers on a time-sharing basis. Furthermore, sub-tasks spawned from infected programs have a high risk of inheriting BUGS.
   
5. How Can You Protect Yourself From BUGS?
   
   (a) Most programs which have errors don't even show it. They may look and behave completely normally. So you cannot tell which ones are infected and which ones are not. To protect yourself, follow these simple guidelines;
   1. (i) The more programs you write, particularly assembler programs, the more chance you have of encountering one which is infected. It is safest to stick to one program.
      FEWER PROGRAMS, LESS RISK
      
      (ii) Unless you are sure of a program, always use a debugger. This will reduce the risk of encountering BUGS.
      USE DEBUGGERS FOR SAFER PROGRAMMING
      
      (iii) It is always best to use a source-level debugger. Low-level debuggers can reduce this protection. Ask your team-leader for advice Anyone who uses assembler programs should not use software interrupts. If you do, never share interrupts (or device handlers, floppies, etc) as you could be introducing BUGS directly into your program.
      DON'T USE SOFTWARE INTERRUPTS. NEVER SHARE.
6. What Should You Do If You Think Your Program Has Been Infected?
   
   If you think your program has been infected, go to your course leader for advice about having a test. Or go directly to your personal tutor for private and confidential advice and a test if you wish. If your program does have errors, they'll let you know and give you help and support.
   
7. What About The Resident Software?
   
   It is not safe to use comms packages, Armstrad applications or on-line dictionaries unless you know they are bug free and have been rigorously tested. Nor is it safe to share a routine or include a file in a program which has been infected.
   
8. What Can't You Get BUGS From?
   
   The government's clear advice for the software industry is that you CANNOT get BUGS from normal use of an infected program. Neither can you get them from reading listings. Nor is there any record of a program becoming infected through sharing comments. There is no danger in sharing floppies or micro-drives. Nor can anyone become infected through using network drives or line printers.
   
   When integrating software, standard precautions should be taken to protect programmers, users and applications. Exporting routines are safe: all the declarations are used only once. All routines used for library builds should be thoroughly checked.
   
9. How Safe Is It In Other Countries?
   
   BUGS exist throughout the world and throughout the computer industry. In certain companies a large number of programs are believed to have BUGS. So it is even more essential to follow the advice given in this message, particularly if you should visit another company. Otherwise, if you do some work on an unfamiliar program, you may inadvertantly affect your regular work when you return.
   
   Furthermore, in some companies, public routines are not checked forBUGS. In those places where errors are widespread you should not, if you can possibly avoid it, use routines from a contract programmer.
   
   In certain start-up companies, routines may not be properly debugged. If you can, avoid using interrupt repairs or patches. If you are in any doubt about these points then discuss them with your course leader.
   
10. Do You Need More Information?
    
    The true picture about BUGS is that, at the moment, relatively few programs are infected with proper full-blown BUGS. Those most at risk are assembler programs which have common code with other assembler programs, programs which share software interrupts, and users of these programs.
    
    But BUGS is spreading. And as it does, so the risk of sharing an infected routine also increases.
    
    Ultimately, defence against BUGS depends on us all taking responsibility for our own logical and programming actions.