Undefined Behaviour in the C Language

Total Page:16

File Type:pdf, Size:1020Kb

Undefined Behaviour in the C Language FAKULTA INFORMATIKY, MASARYKOVA UNIVERZITA Undefined Behaviour in the C Language BAKALÁŘSKÁ PRÁCE Tobiáš Kamenický Brno, květen 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Vedoucí práce: RNDr. Adam Rambousek ii Acknowledgements I am very grateful to my supervisor Miroslav Franc for his guidance, invaluable help and feedback throughout the work on this thesis. iii Summary This bachelor’s thesis deals with the concept of undefined behavior and its aspects. It explains some specific undefined behaviors extracted from the C standard and provides each with a detailed description from the view of a programmer and a tester. It summarizes the possibilities to prevent and to test these undefined behaviors. To achieve that, some compilers and tools are introduced and further described. The thesis contains a set of example programs to ease the understanding of the discussed undefined behaviors. Keywords undefined behavior, C, testing, detection, secure coding, analysis tools, standard, programming language iv Table of Contents Declaration ................................................................................................................................ ii Acknowledgements .................................................................................................................. iii Summary .................................................................................................................................. iv Keywords .................................................................................................................................. iv 1 Introduction ..................................................................................................................... 1 2 Compilers and Analysis Tools ........................................................................................... 2 2.1 GCC ........................................................................................................................... 2 2.2 Clang ......................................................................................................................... 3 2.3 Splint ........................................................................................................................ 3 2.4 Cppcheck .................................................................................................................. 4 2.5 Valgrind .................................................................................................................... 4 3 Undefined Behaviors ........................................................................................................ 5 3.1 Demotion of one real floating type to another produces a value outside the range that can be represented (6.3.1.5). ....................................................................................... 7 3.1.1 Programmer View ............................................................................................ 8 3.1.2 Tester View ...................................................................................................... 8 3.2 An lvalue designating an object of automatic storage duration that could have been declared with the register storage class is used in a context that requires the value of the designated object, but the object is uninitialized. (6.3.2.1). ................... 10 3.2.1 Programmer View .......................................................................................... 11 3.2.2 Tester View .................................................................................................... 11 3.3 The program attempts to modify a string literal (6.4.5). ....................................... 13 3.3.1 Programmer View .......................................................................................... 13 3.3.2 Tester View .................................................................................................... 14 3.4 Two pointer types that are required to be compatible are not identically qualified, or are not pointers to compatible types (6.7.6.1). ............................................................ 15 3.4.1 Programmer View .......................................................................................... 15 3.4.2 Tester View .................................................................................................... 16 3.5 The } that terminates a function is reached, and the value of the function call is used by the caller (6.9.1). .................................................................................................. 17 3.5.1 Programmer View .......................................................................................... 18 3.5.2 Tester View .................................................................................................... 18 v 3.6 The signal function is used in a multi-threaded program (7.14.1.1). .................... 19 3.6.1 Programmer View .......................................................................................... 19 3.6.2 Tester View .................................................................................................... 21 3.7 The string pointed to by the mode argument in a call to the fopen function does not exactly match one of the specified character sequences (7.21.5.3). .......................... 22 3.7.1 Programmer View .......................................................................................... 23 3.7.2 Tester View .................................................................................................... 23 3.8 There are insufficient arguments for the format in a call to one of the formatted input/output functions, or an argument does not have an appropriate type (7.21.6.1, 7.21.6.2, 7.29.2.1, 7.29.2.2). .............................................................................................. 25 3.8.1 Programmer View .......................................................................................... 25 3.8.2 Tester View .................................................................................................... 27 3.9 The pointer argument to the free or realloc function does not match a pointer earlier returned by a memory management function, or the space has been deallocated by a call to free or realloc (7.22.3.3, 7.22.3.5). ................................................................ 28 3.9.1 Programmer View .......................................................................................... 29 3.9.2 Tester View .................................................................................................... 30 3.10 The value of the result of an integer arithmetic or conversion function cannot be represented (7.8.2.1, 7.8.2.2, 7.8.2.3, 7.8.2.4, 7.22.6.1, 7.22.6.2, 7.22.1). ....................... 32 3.10.1 Programmer View .......................................................................................... 32 3.10.2 Tester View .................................................................................................... 34 4 Conclusion and Future Work ......................................................................................... 36 Reference List ......................................................................................................................... 38 Attachments ........................................................................................................................... 40 vi 1 Introduction The programming language C does not have so strict specification and thus provides a lot of leeway in terms of the implementation. Instead of strict and complex rules, the language C is designed for better performance, simplicity, and portability. C source code can be compiled on computers with different processors or operating systems only with slight changes. It is the programmer’s concern to write portable code and avoid expressions specific to an architecture (e.g. size of data types). The programmer also has full control over memory management and therefore has to allocate and free the memory himself or herself since there is no default garbage collector to take care of it. All this low level programming has some consequences. It is much easier, even for a very experienced programmer, to make a mistake. With certain mistakes, a program might not compile, produce wrong results, crash, or even act correctly according to programmer’s expectations. But the fact is that anything could happen depending on the circumstances such as registers content. Such an unexpected event is referred to as “undefined behavior” [1, 2]. The C standard [3, Sec. J.2] contains an attachment describing some cases of undefined behavior but it is more a summary than anything else. Further behaviors not included in the attachment are mentioned in the text of the C standard. It is generally assumed that situations leading to undefined behavior will not occur and it is up to the programmer to take care of their appearance. Some compilers and analysis tools are able to recognize a few undefined behaviors in the code. This does not mean, however, that the programmer should not be familiar with them and should not try to reduce the risk of their occurrence. 1 2 Compilers and Analysis Tools In this thesis, the implementation of the C standard was tested
Recommended publications
  • Automatic Detection of Uninitialized Variables
    Automatic Detection of Uninitialized Variables Thi Viet Nga Nguyen, Fran¸cois Irigoin, Corinne Ancourt, and Fabien Coelho Ecole des Mines de Paris, 77305 Fontainebleau, France {nguyen,irigoin,ancourt,coelho}@cri.ensmp.fr Abstract. One of the most common programming errors is the use of a variable before its definition. This undefined value may produce incorrect results, memory violations, unpredictable behaviors and program failure. To detect this kind of error, two approaches can be used: compile-time analysis and run-time checking. However, compile-time analysis is far from perfect because of complicated data and control flows as well as arrays with non-linear, indirection subscripts, etc. On the other hand, dynamic checking, although supported by hardware and compiler tech- niques, is costly due to heavy code instrumentation while information available at compile-time is not taken into account. This paper presents a combination of an efficient compile-time analysis and a source code instrumentation for run-time checking. All kinds of variables are checked by PIPS, a Fortran research compiler for program analyses, transformation, parallelization and verification. Uninitialized array elements are detected by using imported array region, an efficient inter-procedural array data flow analysis. If exact array regions cannot be computed and compile-time information is not sufficient, array elements are initialized to a special value and their utilization is accompanied by a value test to assert the legality of the access. In comparison to the dynamic instrumentation, our method greatly reduces the number of variables to be initialized and to be checked. Code instrumentation is only needed for some array sections, not for the whole array.
    [Show full text]
  • Declaring a Pointer Variable
    Declaring A Pointer Variable Topazine and neighbouring Lothar fubbed some kaiserships so rousingly! Myles teazles devilishly if top-hole Morlee desists or hunker. Archibald is unprincipled and lip-read privatively as fluorometric Tarzan undersells liturgically and about-ship metonymically. Assigning a function returns nothing else to start as a variable that there is vastly different pointers are variables have learned in Identifier: this failure the arch of a pointer. Let us take a closer look that how pointer variables are stored in memory. In these different physical memory address of this chapter, both are intended only between a pointer variable? You have full pack on the pointer addresses and their contents, the compiler allows a segment register or save segment address, C pointer is of special variable that holds the memory address of another variable. Size of declaration, declare a pointer declarations. Pointers should be initialized either when condition are declared or enjoy an assignment. Instead of declaration statement mean it by having as declared and subtraction have. In bold below c program example, simple it mixes a floating point addition and an integer, at definite point static aliasing goes out giving the window. Pointers are so commonly, a c passes function as well, it will run off, you create and arrays and inaccurate terms of const? The arrow points to instant data whose address the pointer stores. The pointers can be used with structures if it contains only value types as its members. This can counter it difficult to track opposite the error. We will moderate a backbone more fragile this.
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [Show full text]
  • Defining the Undefinedness of C
    Technical Report: Defining the Undefinedness of C Chucky Ellison Grigore Ros, u University of Illinois {celliso2,grosu}@illinois.edu Abstract naturally capture undefined behavior simply by exclusion, be- This paper investigates undefined behavior in C and offers cause of the complexity of undefined behavior, it takes active a few simple techniques for operationally specifying such work to avoid giving many undefined programs semantics. behavior formally. A semantics-based undefinedness checker In addition, capturing the undefined behavior is at least as for C is developed using these techniques, as well as a test important as capturing the defined behavior, as it represents suite of undefined programs. The tool is evaluated against a source of many subtle program bugs. While a semantics other popular analysis tools, using the new test suite in of defined programs can be used to prove their behavioral addition to a third-party test suite. The semantics-based tool correctness, any results are contingent upon programs actu- performs at least as well or better than the other tools tested. ally being defined—it takes a semantics capturing undefined behavior to decide whether this is the case. 1. Introduction C, together with C++, is the king of undefined behavior—C has over 200 explicitly undefined categories of behavior, and A programming language specification or semantics has dual more that are left implicitly undefined [11]. Many of these duty: to describe the behavior of correct programs and to behaviors can not be detected statically, and as we show later identify incorrect programs. The process of identifying incor- (Section 2.6), detecting them is actually undecidable even rect programs can also be seen as describing which programs dynamically.
    [Show full text]
  • ACCU 2015 “New” Features in C
    "New" Features in C ACCU 2015 “New” Features in C Dan Saks Saks & Associates www.dansaks.com 1 Abstract The first international standard for the C programming language was C90. Since then, two newer standards have been published, C99 and C11. C99 introduced a significant number of new features. C11 introduced a few more, some of which have been available in compilers for some time. Curiously, many of these added features don’t seem to have caught on. Many C programmers still program in C90. This session explains many of these “new” features, including declarations in for-statements, typedef redefinitions, inline functions, complex arithmetic, extended integer types, variable- length arrays, flexible array members, compound literals, designated initializers, restricted pointers, type-qualified array parameters, anonymous structures and unions, alignment support, non-returning functions, and static assertions. 2 Copyright © 2015 by Daniel Saks 1 "New" Features in C About Dan Saks Dan Saks is the president of Saks & Associates, which offers training and consulting in C and C++ and their use in developing embedded systems. Dan has written columns for numerous print publications including The C/C++ Users Journal , The C++ Report , Software Development , and Embedded Systems Design . He currently writes the online “Programming Pointers” column for embedded.com . With Thomas Plum, he wrote C++ Programming Guidelines , which won a 1992 Computer Language Magazine Productivity Award . He has also been a Microsoft MVP. Dan has taught thousands of programmers around the world. He has presented at conferences such as Software Development and Embedded Systems , and served on the advisory boards for those conferences.
    [Show full text]
  • The Art, Science, and Engineering of Fuzzing: a Survey
    1 The Art, Science, and Engineering of Fuzzing: A Survey Valentin J.M. Manes,` HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo Abstract—Among the many software vulnerability discovery techniques available today, fuzzing has remained highly popular due to its conceptual simplicity, its low barrier to deployment, and its vast amount of empirical evidence in discovering real-world software vulnerabilities. At a high level, fuzzing refers to a process of repeatedly running a program with generated inputs that may be syntactically or semantically malformed. While researchers and practitioners alike have invested a large and diverse effort towards improving fuzzing in recent years, this surge of work has also made it difficult to gain a comprehensive and coherent view of fuzzing. To help preserve and bring coherence to the vast literature of fuzzing, this paper presents a unified, general-purpose model of fuzzing together with a taxonomy of the current fuzzing literature. We methodically explore the design decisions at every stage of our model fuzzer by surveying the related literature and innovations in the art, science, and engineering that make modern-day fuzzers effective. Index Terms—software security, automated software testing, fuzzing. ✦ 1 INTRODUCTION Figure 1 on p. 5) and an increasing number of fuzzing Ever since its introduction in the early 1990s [152], fuzzing studies appear at major security conferences (e.g. [225], has remained one of the most widely-deployed techniques [52], [37], [176], [83], [239]). In addition, the blogosphere is to discover software security vulnerabilities. At a high level, filled with many success stories of fuzzing, some of which fuzzing refers to a process of repeatedly running a program also contain what we consider to be gems that warrant a with generated inputs that may be syntactically or seman- permanent place in the literature.
    [Show full text]
  • Codesonar the SAST Platform for Devsecops
    DATASHEET CodeSonar The SAST Platform for DevSecOps Accelerate Application Security Software teams are under constant pressure to deliver more content with higher complexity, in shorter timeframes, with increased quality and security. Static Application Security Testing is a proven best practice to help software teams deliver the best code in the shortest timeframe. GrammaTech has been a leader in this field for over 15 years with CodeSonar delivering multi-language SAST capabilities for enterprises where software quality and software security matter. DevSecOps - Speed and Scale Language Support Software developers need rapid feedback on security CodeSonar supports many popular languages, including vulnerabilities in their code. CodeSonar can be integrated into C/C++, Java, C# and Android, as well as support for native software development environments, works unobtrusively to binaries in Intel, Arm and PowerPC instruction set architectures. the developer and provides rapid feedback. CodeSonar also supports OASIS SARIF, for exchange of information with other tools in the DevSecOps environment. Examples of Defects Detected • Buffer over- and underruns • Cast and conversion problems • Command injection • Copy-paste error • Concurrency • Ignored return value • Memory leak • Tainted data • Null pointer dereference • Dangerous function • Unused parameter / value And hundreds more Security Quality Privacy Broad coverage of security vulnerabilities, Integration into DevSecOps to improve Checkers that detect performance including OWASP Top10, SANS/CWE 25. quality of the code and developer impacts such as unnecessary test for Support for third party applications efficiency. Find code quality and nullness, creation of redundant objects or through byte code analysis. performance issues at speed. superfluous memory writes. Team Support Built In CodeSonar is designed to support large teams.
    [Show full text]
  • APPLICATION FUNCTIONS 5 - 1 to 5 - 242 5.1 Type Conversion Functions 5 - 2 5.1.1 Bit Type  Word (Signed), Double Word (Signed) Type Conversion
    SAFETY PRECAUTIONS (Always read these instructions before using this product.) Before using MELSEC-Q or -L series programmable controllers, please read the manuals included with each product and the relevant manuals introduced in those manuals carefully, and pay full attention to safety to handle the product correctly. Make sure that the end users read the manuals included with each product, and keep the manuals in a safe place for future reference. A-1 CONDITIONS OF USE FOR THE PRODUCT (1) Mitsubishi programmable controller ("the PRODUCT") shall be used in conditions; i) where any problem, fault or failure occurring in the PRODUCT, if any, shall not lead to any major or serious accident; and ii) where the backup and fail-safe function are systematically or automatically provided outside of the PRODUCT for the case of any problem, fault or failure occurring in the PRODUCT. (2) The PRODUCT has been designed and manufactured for the purpose of being used in general industries. MITSUBISHI SHALL HAVE NO RESPONSIBILITY OR LIABILITY (INCLUDING, BUT NOT LIMITED TO ANY AND ALL RESPONSIBILITY OR LIABILITY BASED ON CONTRACT, WARRANTY, TORT, PRODUCT LIABILITY) FOR ANY INJURY OR DEATH TO PERSONS OR LOSS OR DAMAGE TO PROPERTY CAUSED BY the PRODUCT THAT ARE OPERATED OR USED IN APPLICATION NOT INTENDED OR EXCLUDED BY INSTRUCTIONS, PRECAUTIONS, OR WARNING CONTAINED IN MITSUBISHI'S USER, INSTRUCTION AND/OR SAFETY MANUALS, TECHNICAL BULLETINS AND GUIDELINES FOR the PRODUCT. ("Prohibited Application") Prohibited Applications include, but not limited to, the use of the PRODUCT in; • Nuclear Power Plants and any other power plants operated by Power companies, and/or any other cases in which the public could be affected if any problem or fault occurs in the PRODUCT.
    [Show full text]
  • Grammatech Codesonar Product Datasheet
    GRAMMATECH CODESONAR PRODUCT DATASHEET Static Code Analysis and Static Application Security Testing Software Assurance Services Delivered by a senior software CodeSonar empowers teams to quickly analyze and validate the code – source and/or binary – engineer, the software assurance identifying serious defects or bugs that cause cyber vulnerabilities, system failures, poor services focus on automating reliability, or unsafe conditions. reporting on your software quality, creating an improvement plan and GrammaTech’s Software Assurance Services provide the benets of CodeSonar to your team in measuring your progress against that an accelerated timeline and ensures that you make the best use of SCA and SAST. plan. This provides your teams with reliable, fast, actionable data. GrammaTech will manage the static Enjoy the Benets of the Deepest Static Analysis analysis engine on your premises for you, such that your resources can Employ Sophisticated Algorithms Comply with Coding Standards focus on developing software. The following activities are covered: CodeSonar performs a unied dataow and CodeSonar supports compliance with standards symbolic execution analysis that examines the like MISRA C:2012, IS0-26262, DO-178B, Integration in your release process computation of the entire program. The US-CERT’s Build Security In, and MITRE’S CWE. Integration in check-in process approach does not rely on pattern matching or similar approximations. CodeSonar’s deeper Automatic assignment of defects analysis naturally nds defects with new or Reduction of parse errors unusual patterns. Review of warnings Analyze Millions of Lines of Code Optimization of conguration CodeSonar can perform a whole-program Improvement plan and tracking analysis on 10M+ lines of code.
    [Show full text]
  • Codesonar for C# Datasheet
    DATASHEET CodeSonar C# SAST when Safety and Security Matter Accelerate Application Security Software teams are under constant pressure to deliver more content with higher complexity, in shorter timeframes, with increased quality and security. Static Application Security Testing is a proven best practice to help software teams deliver the best code in the shortest timeframe. GrammaTech has been a leader in this field for over 15 years with CodeSonar delivering C# multi-language SAST capabilities for enterprises where software quality and software security matter. DevSecOps - Speed and Scale Abstract Interpretation Software developers need rapid feedback on security GrammaTech SAST tools use the concept of abstract vulnerabilities in their work artifacts. CodeSonar can be interpretation to statically examine all the paths through the integrated into software development environments, can work application and understand the values of variables and how they unobtrusively to the developer and provide rapid feedback. impact program state. Abstract interpretation gives CodeSonar for C# the highest scores in vulnerability benchmarks. Security Quality Privacy Broad coverage of security vulnerabilities, Integration into DevSecOps to improve Checkers that detect performance including OWASP Top10, SANS/CWE 25. quality of the code and developer impacts such as unnecessary test for Support for third party applications efficiency. Find code quality and nullness, creation of redundant objects or through byte code analysis. performance issues at speed. superfluous memory writes. Use Cases Enterprise customers are using C# in their internal applications, either in-house built, or built by a third-party. Static analysis is needed to to improve security and quality to drive business continuity. Mobile and Client customers are using C# on end-points, sometimes in an internet-of-things deployment, or to provide information to mobile users.
    [Show full text]
  • Software Vulnerabilities Principles, Exploitability, Detection and Mitigation
    Software vulnerabilities principles, exploitability, detection and mitigation Laurent Mounier and Marie-Laure Potet Verimag/Université Grenoble Alpes GDR Sécurité – Cyber in Saclay (Winter School in CyberSecurity) February 2021 Software vulnerabilities . are everywhere . and keep going . 2 / 35 Outline Software vulnerabilities (what & why ?) Programming languages (security) issues Exploiting a sofwtare vulnerability Software vulnerabilities mitigation Conclusion Example 1: password authentication Is this code “secure” ? boolean verify (char[] input, char[] passwd , byte len) { // No more than triesLeft attempts if (triesLeft < 0) return false ; // no authentication // Main comparison for (short i=0; i <= len; i++) if (input[i] != passwd[i]) { triesLeft-- ; return false ; // no authentication } // Comparison is successful triesLeft = maxTries ; return true ; // authentication is successful } functional property: verify(input; passwd; len) , input[0::len] = passwd[0::len] What do we want to protect ? Against what ? I confidentiality of passwd, information leakage ? I control-flow integrity of the code I no unexpected runtime behaviour, etc. 3 / 35 Example 2: make ‘python -c ’print "A"*5000’‘ run make with a long argument crash (in recent Ubuntu versions) Why do we need to bother about crashes (wrt. security) ? crash = consequence of an unexpected run-time error not trapped/foreseen by the programmer, nor by the compiler/interpreter ) some part of the execution: I may take place outside the program scope/semantics I but can be controled/exploited by an attacker (∼ “weird machine”) out of scope execution runtime error crash normal execution possibly exploitable ... security breach ! ,! may break all security properties ... from simple denial-of-service to arbitrary code execution Rk: may also happen silently (without any crash !) 4 / 35 Back to the context: computer system security what does security mean ? I a set of general security properties: CIA Confidentiality, Integrity, Availability (+ Non Repudiation + Anonymity + .
    [Show full text]
  • THE 1995 STANDARD MUMPS POCKET GUIDE Fifth Edition of the Mumps Pocket Guide Second Printing
    1995 S TA N DA R D M U M P S P O C K E T G U I D E FIFTH EDITION FREDERICK D. S. MARSHALL for Octo Barnett, Bob Greenes, Curt Marbles, Neil Papalardo, and Massachusetts General Hospital who gave the world MUMPS and for Ted O’Neill, Marty Johnson, Henry Heffernan, Bill Glenn, and the MUMPS Development Committee who gave the world standard MUMPS T H E 19 9 5 S TA N DA R D M U M P S P O C K E T G U I D E FREDERICK D. S. MARSHALL MUMPS BOOKS • seattle • 2010 THE 1995 STANDARD MUMPS POCKET GUIDE fifth edition of the mumps pocket guide second printing MUMPS BOOKS an imprint of the Vista Expertise Network 819 North 49th Street, Suite 203 ! Seattle, Washington 98103 www.vistaexpertise.net [email protected] (206) 632-0166 copyright © 2010 by frederick d. s. marshall All rights reserved. V I S t C E X P E R T I S E N E T W O R K C O N T E N T S 1 ! I N T R O D U C T I O N ! 1 1.1 ! Purpose ! 1 1.2 ! Acknowledgments ! 1 2 ! O T H E R R E F E R E N C E S ! 2 3 ! T H E S U I T E O F S T A N D A R D S ! 3 4 ! S Y S T E M M O D E L ! 5 4.1 ! Multi-processing ! 5 4.2 ! Data ! 5 4.3 ! Code ! 7 4.4 ! Environments ! 7 4.5 ! Pack ages ! 7 4.6 ! Char acter Sets ! 7 4.7 ! Input/Output Devices ! 8 5 ! S Y N T A X ! 9 5.1 ! Metalanguage Element Index ! 9 6 ! R O U T I N E S ! 15 6.1 ! Routine Structure ! 15 6.2 ! Lines ! 15 6.3 ! Line References ! 17 6.4 ! Execution ! 19 6.4.1 ! the process stack ! 19 6.4.2 ! block Processing ! 19 6.4.3 ! error codes ! 21 7 ! E X P R E S S I O N S ! 2 3 7.1 ! Values ! 24 7.1.1 ! representation ! 24 7.1.2 ! interpretation
    [Show full text]