Programming With(Out) the GOTO

Total Page:16

File Type:pdf, Size:1020Kb

Programming With(Out) the GOTO Programming With(out) the GOTO B .M . Leavenworth, IB M A brief history of the goto controversy (retentio n 1. Since transfer of control is subsumed b y or deletion of the goto statement) is presented . more powerful notions, to wit : After considering some of the theoretical an d sequential executio n practical aspects of the problem, a summary o f procedure call and retur n arguments both for and against the goto is given . conditional expression (statement ) repetition clause (for statemen t KEY WORDS AND PHRASES : goto statement, comput- in ALGOL, DO group in PL/I ) ability theory, goto-less programming, combinatory is not the programmer led astray by givin g logic, lambda calculus, Post systems, Markov algo- him control over it ? rithms, Turing machines, structured programming , 2. The solution of the halting problem (th e . control structures determination of whether a given program ter- CR CATEGORIES : 1 .3, 4 .2, 5 . 2 minates) is made difficult by the unrestricte d use of the goto statement . After eliminatio n INTRODUCTION of the goto, there are only two ways in whic h a program may fail to stop : either by infinit e There are a number of issues connected wit h recursion, or by the repetition clause , the retention or deletion of the goto statemen t in programs or programming languages, and w e Val Schorre reported in 1966 (S1) on th e attempt to set the stage for a discussion of thes e development of two procedural languages, LISPX an d issues by giving a brief history of the goto con- MOL-32, without the goto . Further, that he ha d troversy . The possibility of eliminating the got o been writing programs since 1960 in outline for m has both theoretical and practical aspects . It i s using the principle of nested flow . These outlines , of interest to discover that the goto does no t which served the purpose of flow charts, showed th e appear in most formal systems of computabilit y flow of control graphically by indentation, an d theory, but does appear in programming languag e were used as original documentation of the program , extensions of these systems . Since programmin g which was coded in assembly language from the out - style is an important component of the controversy , line . This may be the first recorded instance o f we give one example of the influence of a hig h "goto-less " procedural programming (as distinc t level language on programming style, and its re- from functional programming in LISP), albeit not i n lation to the goto statement . Finally, a summar y a high level language . of arguments both for and against the goto i s Professor Van Wijngaarden (Vl) showed that th e given . goto statement could, in principle, be eliminate d from ALGOL 60 programs by a preprocessing algorith m HISTORY which replaced the set of given programming con- structs by a smaller set of equivalent concepts . The proposition that there might be somethin g The purpose of this demonstration was the expli- wrong with the goto statement, one of the pillar s cation of syntax and semantics, rather than 'goto- of practical programming since the invention o f less " programming . FORTRAN, has slowly penetrated the consciousnes s Peter Landin also argued in 1966 (L3) for a of programmers since Dijkstra ' s famous letter i n style of programming which eliminates not only th e the Communications of the ACM (D4) . Actually , goto, but the notion of explicit sequencing an d Professor Dijkstra considered programming language s assignment as well . Landin introduced a languag e without benefit of either assignment or goto in a called ISWIM, and used a purely functional subse t paper presented at the 1965 IFIP Congress (D2) . H e of this language to program in this style . I t concluded that a language without the former wa s should be noted, however, that ISWI?I contains im- elegant but inadequate . As to the latter, he enun- perative features such as " program points " , roughl y ciated the criterion that the quality of a program- analogous to labels, and assignment so that th e mer was inversely proportional to the density o f programmer has an out . We shall see that thi s 2oto statements in his program . While admittin g theme constantly recurs in what follows . the possibility of a conflict between convenienc e and efficiency, he made the following points, whic h COMPUTABILITY THEORY WITH[OUT] THE GOT O are paraphrased below, Although the formal systems of computabilit y theory (see below) have for the most part theo - 54 retical rather than practical significance, they statements in ALGOL and PL/I so that they coul d demonstrate that the goto is not needed as a prim- write itive in order to compute all computable functions . IF expr THEN DO It is interesting to discover, however, that th e ; . ' END ; goto has been included in pragmatic extensions t o continued to writ e these systems . The goto does not appear in the following for - IF expr THEN GO TO LAB ; mal systems : from force of habit . Thus we see the influenc e that machine primitives have exerted through th e Formal System programming Extensio n present evolution of high level programming lan- combinatory logic of a jumping operator ' J ' guages ! Curry & Feys (Cll), and was defined by Landi n the lambda calculus of (L3) in ISWIN, which i s SUMMARY OF ISSUE S Church (C4) an extension of th e lambda calculu s Since the theoretical possibility of elimi - nating the goto has been demonstrated, it wil l Post systems (P5) and labelled Markov algor - not be discussed further . We will therefor e Narkov algorithms (Ml) ithms with branchin g attempt to summarize the practical arguments bot h were defined by Cara- for and against the goto . The arguments for elimi - cciolo et al (Cl), an d nating the goto (at the same time, replacing it b y the language CO>IIT (Yl ) other control structures) are essentially the fol- and SNOBOL (Fl) can b e lowing : considered to be exten- 1 . Goto-less sions of Markov algor - programs are easier to understand , ithms with goto command s debug and modify . This is the structured o r top-down programming argument (D2) (D4) (D6 ) Kleene general recur- LISP (212), which was als o (ES) (W7) (W8) (W9) . sive functions (Kl) strongly influenced b y the lambda calculus, ha s 2, If the goto statement is not replaced b y more sophisticated control structures, th e the PROG feature which allows assignment an d programmer is likely to misuse it (the goto. ) goto (see below ) in order to synthesize those structures (D4 ) (W9) . We see in each case that the goto is missing i n 3 . It is easier to prove assertions about " goto- the pristine form of the system, but has been adde d less " programs (L3) (P3) (S3) . in programming extensions (whether for the sake o f tradition or " convenience" is a matter for debate) . The technical means of replacing gotos b y The FROG feature (B5) was added to LISP in order t o other control structures are as follows : incorporate the goto, among other things, althoug h 1. by recursive procedures . This is a theo- a wide range of applications have been written i n retical, rather than a practical, device (V1 ) pure (no assignment or goto) LISP . (K2) . The goto appears in Turing machines (Ti) (sinc e instructions or states have explicit successors) , 2. by the while construction . This can al - and related automata such as Minsky's program ma - ways be done without changing the progra m chines (M6) . It also appears in program schemat a topology, by the introduction of auxiliary (L7), which can be characterized as flow charts wit h variables (Al) . assignment statements in the boxes . And finally , 3. by node splitting . This requires redundan t it appears in the order codes of the general pur- code or procedure calls (K2) (W7) . pose computer . The arguments against eliminating the goto ca n THE INFLUENCE OF NOTATIO N be surmarized as follows : 1. the goto is needed for abnormal exits fro m It may be truly said that the goto statement i n a block or procedure . The ' repeat-exit' mech- its form as a machine primitive has profoundly in- anism of Knuth and Floyd (K2) only allows a one - fluenced the long line of procedural high level lan- level exit, whereas Wulf ' s leave constructio n guage descendants . We wish to explore this poin t 0?7) requires the reintroduction of labels fo r and its relation to what shall be called the FORTRA N multi-level exits . As Landin (L3) has admitted , II IF Syndrome . " the most recalcitrant uses of explicit sequenc- The FORTRAN II IF statement --- IF (expr ) ing appear to be associated with success/failur e nl, n2, n3 ---- is a prime example of the power o f situations and the action needed on failure , language to influence program organization, an d probably corrupted a generation of programmers . 2. the goto is often more efficient . For, con- sider the overhead introduced by node splittin g This statement effectively generates multiple goto s (which reflect the unconditional transfers in ma - and the while construction (setting of flags) . Also, Knuth and Floyd (K2) have pointed out tha t chine code), as can be seen by the equivalent PL R procedure calls can sometimes be replaced b y statements : goto statements . IF expr < 0 THEN GO TO nl ; IF expr = 0 THEN GO TO n2 ; 3.
Recommended publications
  • Preview Objective-C Tutorial (PDF Version)
    Objective-C Objective-C About the Tutorial Objective-C is a general-purpose, object-oriented programming language that adds Smalltalk-style messaging to the C programming language. This is the main programming language used by Apple for the OS X and iOS operating systems and their respective APIs, Cocoa and Cocoa Touch. This reference will take you through simple and practical approach while learning Objective-C Programming language. Audience This reference has been prepared for the beginners to help them understand basic to advanced concepts related to Objective-C Programming languages. Prerequisites Before you start doing practice with various types of examples given in this reference, I'm making an assumption that you are already aware about what is a computer program, and what is a computer programming language? Copyright & Disclaimer © Copyright 2015 by Tutorials Point (I) Pvt. Ltd. All the content and graphics published in this e-book are the property of Tutorials Point (I) Pvt. Ltd. The user of this e-book can retain a copy for future reference but commercial use of this data is not allowed. Distribution or republishing any content or a part of the content of this e-book in any manner is also not allowed without written consent of the publisher. We strive to update the contents of our website and tutorials as timely and as precisely as possible, however, the contents may contain inaccuracies or errors. Tutorials Point (I) Pvt. Ltd. provides no guarantee regarding the accuracy, timeliness or completeness of our website or its contents including this tutorial. If you discover any errors on our website or in this tutorial, please notify us at [email protected] ii Objective-C Table of Contents About the Tutorial ..................................................................................................................................
    [Show full text]
  • A Universal Modular ACTOR Formalism for Artificial
    Artificial Intelligence A Universal Modular ACTOR Formalism for Artificial Intelligence Carl Hewitt Peter Bishop Richard Steiger Abstract This paper proposes a modular ACTOR architecture and definitional method for artificial intelligence that is conceptually based on a single kind of object: actors [or, if you will, virtual processors, activation frames, or streams]. The formalism makes no presuppositions about the representation of primitive data structures and control structures. Such structures can be programmed, micro-coded, or hard wired 1n a uniform modular fashion. In fact it is impossible to determine whether a given object is "really" represented as a list, a vector, a hash table, a function, or a process. The architecture will efficiently run the coming generation of PLANNER-like artificial intelligence languages including those requiring a high degree of parallelism. The efficiency is gained without loss of programming generality because it only makes certain actors more efficient; it does not change their behavioral characteristics. The architecture is general with respect to control structure and does not have or need goto, interrupt, or semaphore primitives. The formalism achieves the goals that the disallowed constructs are intended to achieve by other more structured methods. PLANNER Progress "Programs should not only work, but they should appear to work as well." PDP-1X Dogma The PLANNER project is continuing research in natural and effective means for embedding knowledge in procedures. In the course of this work we have succeeded in unifying the formalism around one fundamental concept: the ACTOR. Intuitively, an ACTOR is an active agent which plays a role on cue according to a script" we" use the ACTOR metaphor to emphasize the inseparability of control and data flow in our model.
    [Show full text]
  • On Goto Statement in Basic
    On Goto Statement In Basic James spores his coeditor arrest lowse, but ribbony Clarence never perambulating so defenselessly. orFingered ferniest and after sold grapy Barry Jimmy sublime countermarches his microclimates so thwart? envelop snigs opinionatively. Is Skylar mismatched Download On Goto Statement In Basic pdf. Download On Goto Statement In Basic doc. Well before withthe statement recursion, basic, and look understandable like as labe not, usage i learned of. Normal to that precedence include support that the content goto basic;is a goto. back Provided them up by statementthe adjectives basic, novel the anddim knowsstatement exactly with be the in below. basic doesMany not and supported the active for on the goto vba. in theSkip evil the comes error asfrom on movesthe specified to go toworkbook go with thename _versionname_ to see the value home does page. not Activeprovided on byone this is withinsurvey? different Outline if ofa trailingbasic withinspace theor responding value if by thisto. Repaired page? Print in favor statement of code along so we with need recursion: to go with many the methods product. becomeThought of goto is startthousands running of intothe code?more readable Slightly moreand in instances vb. Definitely that runnot onprovided basic program, by a more goto explicit that construct,exponentiation, basic i moreinterpreter about? jump Stay to thatadd youthe workbookwhen goto name. basic commandPrediction gotoor go used, on statement we were basicnot, same moves page to the returns slightly isresults a boolean specific in toworkbook the trademarks name to of. the Day date is of.another Exactly if you what forgot you runa stack on in overflow basic does but misusingnot complete it will code isgenerally the window.
    [Show full text]
  • 7. Control Flow First?
    Copyright (C) R.A. van Engelen, FSU Department of Computer Science, 2000-2004 Ordering Program Execution: What is Done 7. Control Flow First? Overview Categories for specifying ordering in programming languages: Expressions 1. Sequencing: the execution of statements and evaluation of Evaluation order expressions is usually in the order in which they appear in a Assignments program text Structured and unstructured flow constructs 2. Selection (or alternation): a run-time condition determines the Goto's choice among two or more statements or expressions Sequencing 3. Iteration: a statement is repeated a number of times or until a Selection run-time condition is met Iteration and iterators 4. Procedural abstraction: subroutines encapsulate collections of Recursion statements and subroutine calls can be treated as single Nondeterminacy statements 5. Recursion: subroutines which call themselves directly or indirectly to solve a problem, where the problem is typically defined in terms of simpler versions of itself 6. Concurrency: two or more program fragments executed in parallel, either on separate processors or interleaved on a single processor Note: Study Chapter 6 of the textbook except Section 7. Nondeterminacy: the execution order among alternative 6.6.2. constructs is deliberately left unspecified, indicating that any alternative will lead to a correct result Expression Syntax Expression Evaluation Ordering: Precedence An expression consists of and Associativity An atomic object, e.g. number or variable The use of infix, prefix, and postfix notation leads to ambiguity An operator applied to a collection of operands (or as to what is an operand of what arguments) which are expressions Fortran example: a+b*c**d**e/f Common syntactic forms for operators: The choice among alternative evaluation orders depends on Function call notation, e.g.
    [Show full text]
  • Gnu Smalltalk Library Reference Version 3.2.5 24 November 2017
    gnu Smalltalk Library Reference Version 3.2.5 24 November 2017 by Paolo Bonzini Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". 1 3 1 Base classes 1.1 Tree Classes documented in this manual are boldfaced. Autoload Object Behavior ClassDescription Class Metaclass BlockClosure Boolean False True CObject CAggregate CArray CPtr CString CCallable CCallbackDescriptor CFunctionDescriptor CCompound CStruct CUnion CScalar CChar CDouble CFloat CInt CLong CLongDouble CLongLong CShort CSmalltalk CUChar CByte CBoolean CUInt CULong CULongLong CUShort ContextPart 4 GNU Smalltalk Library Reference BlockContext MethodContext Continuation CType CPtrCType CArrayCType CScalarCType CStringCType Delay Directory DLD DumperProxy AlternativeObjectProxy NullProxy VersionableObjectProxy PluggableProxy SingletonProxy DynamicVariable Exception Error ArithmeticError ZeroDivide MessageNotUnderstood SystemExceptions.InvalidValue SystemExceptions.EmptyCollection SystemExceptions.InvalidArgument SystemExceptions.AlreadyDefined SystemExceptions.ArgumentOutOfRange SystemExceptions.IndexOutOfRange SystemExceptions.InvalidSize SystemExceptions.NotFound SystemExceptions.PackageNotAvailable SystemExceptions.InvalidProcessState SystemExceptions.InvalidState
    [Show full text]
  • Inf 212 Analysis of Prog. Langs Elements of Imperative Programming Style
    INF 212 ANALYSIS OF PROG. LANGS ELEMENTS OF IMPERATIVE PROGRAMMING STYLE Instructors: Kaj Dreef Copyright © Instructors. Objectives Level up on things that you may already know… ! Machine model of imperative programs ! Structured vs. unstructured control flow ! Assignment ! Variables and names ! Lexical scope and blocks ! Expressions and statements …so to understand existing languages better Imperative Programming 3 Oldest and most popular paradigm ! Fortran, Algol, C, Java … Mirrors computer architecture ! In a von Neumann machine, memory holds instructions and data Control-flow statements ! Conditional and unconditional (GO TO) branches, loops Key operation: assignment ! Side effect: updating state (i.e., memory) of the machine Simplified Machine Model 4 Registers Code Data Stack Program counter Environment Heap pointer Memory Management 5 Registers, Code segment, Program counter ! Ignore registers (for our purposes) and details of instruction set Data segment ! Stack contains data related to block entry/exit ! Heap contains data of varying lifetime ! Environment pointer points to current stack position ■ Block entry: add new activation record to stack ■ Block exit: remove most recent activation record Control Flow 6 Control flow in imperative languages is most often designed to be sequential ! Instructions executed in order they are written ! Some also support concurrent execution (Java) But… Goto in C # include <stdio.h> int main(){ float num,average,sum; int i,n; printf("Maximum no. of inputs: "); scanf("%d",&n); for(i=1;i<=n;++i){
    [Show full text]
  • Fiendish Designs
    Fiendish Designs A Software Engineering Odyssey © Tim Denvir 2011 1 Preface These are notes, incomplete but extensive, for a book which I hope will give a personal view of the first forty years or so of Software Engineering. Whether the book will ever see the light of day, I am not sure. These notes have come, I realise, to be a memoir of my working life in SE. I want to capture not only the evolution of the technical discipline which is software engineering, but also the climate of social practice in the industry, which has changed hugely over time. To what extent, if at all, others will find this interesting, I have very little idea. I mention other, real people by name here and there. If anyone prefers me not to refer to them, or wishes to offer corrections on any item, they can email me (see Contact on Home Page). Introduction Everybody today encounters computers. There are computers inside petrol pumps, in cash tills, behind the dashboard instruments in modern cars, and in libraries, doctors’ surgeries and beside the dentist’s chair. A large proportion of people have personal computers in their homes and may use them at work, without having to be specialists in computing. Most people have at least some idea that computers contain software, lists of instructions which drive the computer and enable it to perform different tasks. The term “software engineering” wasn’t coined until 1968, at a NATO-funded conference, but the activity that it stands for had been carried out for at least ten years before that.
    [Show full text]
  • Jalopy User's Guide V. 1.9.4
    Jalopy - User’s Guide v. 1.9.4 Jalopy - User’s Guide v. 1.9.4 Copyright © 2003-2010 TRIEMAX Software Contents Acknowledgments . vii Introduction . ix PART I Core . 1 CHAPTER 1 Installation . 3 1.1 System requirements . 3 1.2 Prerequisites . 3 1.3 Wizard Installation . 4 1.3.1 Welcome . 4 1.3.2 License Agreement . 5 1.3.3 Installation Features . 5 1.3.4 Online Help System (optional) . 8 1.3.5 Settings Import (optional) . 9 1.3.6 Configure plug-in Defaults . 10 1.3.7 Confirmation . 11 1.3.8 Installation . 12 1.3.9 Finish . 13 1.4 Silent Installation . 14 1.5 Manual Installation . 16 CHAPTER 2 Configuration . 17 2.1 Overview . 17 2.1.1 Preferences GUI . 18 2.1.2 Settings files . 29 2.2 Global . 29 2.2.1 General . 29 2.2.2 Misc . 32 2.2.3 Auto . 35 2.3 File Types . 36 2.3.1 File types . 36 2.3.2 File extensions . 37 2.4 Environment . 38 2.4.1 Custom variables . 38 2.4.2 System variables . 40 2.4.3 Local variables . 41 2.4.4 Usage . 42 2.4.5 Date/Time . 44 2.5 Exclusions . 44 2.5.1 Exclusion patterns . 45 2.6 Messages . 46 2.6.1 Categories . 47 2.6.2 Logging . 48 2.6.3 Misc . 49 2.7 Repository . 49 2.7.1 Searching the repository . 50 2.7.2 Displaying info about the repository . 50 2.7.3 Adding libraries to the repository . 50 2.7.4 Removing the repository .
    [Show full text]
  • C Style and Coding Standards
    -- -- -1- C Style and Coding Standards Glenn Skinner Suryakanta Shah Bill Shannon AT&T Information System Sun Microsystems ABSTRACT This document describes a set of coding standards and recommendations for programs written in the C language at AT&T and Sun Microsystems. The purpose of having these standards is to facilitate sharing of each other’s code, as well as to enable construction of tools (e.g., editors, formatters). Through the use of these tools, programmers will be helped in the development of their programs. This document is based on a similar document written by L.W. Cannon, R.A. Elliott, L.W. Kirchhoff, J.H. Miller, J.M. Milner, R.W. Mitze, E.P. Schan, N.O. Whittington at Bell Labs. -- -- -2- C Style and Coding Standards Glenn Skinner Suryakanta Shah Bill Shannon AT&T Information System Sun Microsystems 1. Introduction The scope of this document is the coding style used at AT&T and Sun in writing C programs. A common coding style makes it easier for several people to cooperate in the development of the same program. Using uniform coding style to develop systems will improve readability and facilitate maintenance. In addition, it will enable the construction of tools that incorporate knowledge of these standards to help programmers in the development of programs. For certain style issues, such as the number of spaces used for indentation and the format of variable declarations, no clear consensus exists. In these cases, we have documented the various styles that are most frequently used. We strongly recommend, however, that within a particular project, and certainly within a package or module, only one style be employed.
    [Show full text]
  • The Latest IBM Z COBOL Compiler: Enterprise COBOL V6.2!
    The latest IBM Z COBOL compiler: Enterprise COBOL V6.2! Tom Ross Captain COBOL SHARE Providence August 7,2017 1 COBOL V6.2 ? YES! • The 4 th release of the new generation of IBM Z COBOL compilers • Announced: July 17, 2017 • The same day as IBM z14 hardware…coincidence? • GA: September 8, 2017 • Compiler support for the new IBM z14 hardware and IBM z/OS V2.3 • Ability to exploit the new Vector Packed Decimal Facility of z14 • ‘OLD’ news: • COBOL V5 EOM Sept 11, 2017 (announced Dec 6, 2016) • EOS for COBOL V4 ‘might’ be earlier than 2020, still discussing 2 COBOL V6.2 ? What else does it have? • New and changed COBOL statements, such as the new JSON PARSE statement • Support of COBOL 2002/2014 standards with the addition of the COBOL Conditional Compilation language feature • New and changed COBOL options for increased flexibility • Improved compiler listings with compiler messages at the end of the listing as in previous releases of the compiler • Improved interfaces to optional products and tools such as IBM Debug for z Systems (formerly Debug Tool for z/OS) and IBM Application Discovery and Delivery Intelligence (formerly EzSource) • Compile-time and runtime performance enhancements • Improved usability of the compiler in the z/OS UNIX System Services environment 3 Vector Packed Decimal Facility of z14 • Enterprise COBOL V6.2 adds support for exploiting the new Vector Packed Decimal Facility in z14 through the ARCH(12) compiler option. • The Vector Packed Decimal Facility allows the dominant COBOL data types, packed and zoned decimal, to be handled in wide 16-byte vector registers instead of in memory.
    [Show full text]
  • Programming Reference Guide
    Programming Reference Guide REFERENCE GUIDE RG-0006-01 1.9 en-US ENGLISH Important User Information Disclaimer The information in this document is for informational purposes only. Please inform HMS Networks of any inaccuracies or omissions found in this document. HMS Networks disclaims any responsibility or liability for any errors that may appear in this document. HMS Networks reserves the right to modify its products in line with its policy of continuous product development. The information in this document shall therefore not be construed as a commitment on the part of HMS Networks and is subject to change without notice. HMS Networks makes no commitment to update or keep current the information in this document. The data, examples and illustrations found in this document are included for illustrative purposes and are only intended to help improve understanding of the functionality and handling of the product. In view of the wide range of possible applications of the product, and because of the many variables and requirements associated with any particular implementation, HMS Networks cannot assume responsibility or liability for actual use based on the data, examples or illustrations included in this document nor for any damages incurred during installation of the product. Those responsible for the use of the product must acquire sufficient knowledge in order to ensure that the product is used correctly in their specific application and that the application meets all performance and safety requirements including any applicable laws, regulations, codes and standards. Further, HMS Networks will under no circumstances assume liability or responsibility for any problems that may arise as a result from the use of undocumented features or functional side effects found outside the documented scope of the product.
    [Show full text]
  • FORTRAN 77 Language Reference
    FORTRAN 77 Language Reference FORTRAN 77 Version 5.0 901 San Antonio Road Palo Alto, , CA 94303-4900 USA 650 960-1300 fax 650 969-9131 Part No: 805-4939 Revision A, February 1999 Copyright Copyright 1999 Sun Microsystems, Inc. 901 San Antonio Road, Palo Alto, California 94303-4900 U.S.A. All rights reserved. All rights reserved. This product or document is protected by copyright and distributed under licenses restricting its use, copying, distribution, and decompilation. No part of this product or document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Portions of this product may be derived from the UNIX® system, licensed from Novell, Inc., and from the Berkeley 4.3 BSD system, licensed from the University of California. UNIX is a registered trademark in the United States and in other countries and is exclusively licensed by X/Open Company Ltd. Third-party software, including font technology in this product, is protected by copyright and licensed from Sun’s suppliers. RESTRICTED RIGHTS: Use, duplication, or disclosure by the U.S. Government is subject to restrictions of FAR 52.227-14(g)(2)(6/87) and FAR 52.227-19(6/87), or DFAR 252.227-7015(b)(6/95) and DFAR 227.7202-3(a). Sun, Sun Microsystems, the Sun logo, SunDocs, SunExpress, Solaris, Sun Performance Library, Sun Performance WorkShop, Sun Visual WorkShop, Sun WorkShop, and Sun WorkShop Professional are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and in other countries.
    [Show full text]