DOCSLIB.ORG

Dynamic Analysis for Javascript Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Dynamic Analysis for Javascript Code Dynamic Analysis for JavaScript Code by Liang Gong A dissertation submitted in partial satisfaction of the requirements for the degree of Doctor of Philosophy in Computer Sciences in the GRADUATE DIVISION of the UNIVERSITY OF CALIFORNIA, BERKELEY Committee in charge: Professor Koushik Sen, Chair Professor David Wagner Professor Vern Paxson Professor Sara McMains Spring 2018 Dynamic Analysis for JavaScript Code Copyright © 2018 by Liang Gong Abstract Dynamic Analysis for JavaScript Code by Liang Gong Doctor of Philosophy in Computer Sciences University of California, Berkeley Professor Koushik Sen, Chair The eectiveness of the widely adopted static analysis tools is often limited by JavaScript’s dynamic nature and the need to over-approximate runtime behaviors. To tackle this challenge, we research robust dynamic analysis techniques for real-world JavaScript code. To analyze front-end web applications, we rst extend Jalangi which is a dynamic analy- sis framework based on source code instrumentation. Our extension of Jalangi intercepts and rewrites JavaScript code during network transmission. We also develop NodeSec, which is a dy- namic instrumentation framework that traces and sandboxes the interactions between a Node.js program and the operating system. Based on the two frameworks, we research dynamic analysis techniques to detect correctness, performance, and security issues in JavaScript code. First, we present DLint, a dynamic analysis approach to check code quality rules in JavaScript. DLint consists of a generic framework and an extensible set of checkers that each addresses a particular rule. We formally describe and implement 28 checkers that address prob- lems missed by state-of-the-art static approaches. Applying the approach in an empirical study on over 200 popular web sites shows that static and dynamic checking complement each other. On average per web site, DLint detects 49 problems that are missed statically, including visible bugs on the web sites of IKEA, Hilton, eBay, and CNBC. Second, we present JITProf, a proling framework to dynamically identify JIT-unfriendly code, which prohibits protable JIT optimizations. The key idea is to associate meta-information with JavaScript objects and code locations, to update this information whenever particular run- time events occur, and to use the meta-information to identify JIT-unfriendly operations. We use JITProf to analyze widely used JavaScript web applications and show that JIT-unfriendly code is prevalent in practice. We show that refactoring JIT-unfriendly code identied by JITProf leads to statistically signicant performance improvements of up to 26.3% in 15 popular benchmarks. Finally, we conduct the rst large-scale empirical study of security issues on over 330,000 npm packages. We adopted an iterative approach to dynamically analyze those packages and identied 360 previously unknown malicious or vulnerable packages, 315 of which have been validated by the community so far; 258 of those issues are considered as highly severe. All those packages with security issues in aggregate have 2,138 downloads per day, stressing the risks for the Node.js ecosystem. 1 Contents Contents i List of Figures v List of Tables vi Acknowledgments vii 1 Introduction 1 1.1 JavaScript — the Good, the Bad, and the Ugly . .1 1.2 Dealing with Problematic Features . .2 1.3 Outline and Previously Published Work . .5 2 Related Work 6 2.1 Static Analysis . .6 2.2 Symbolic Execution and Concolic Execution . .7 2.3 Dynamic Analysis Infrastructure . .8 2.3.1 Runtime Instrumentation . .8 2.3.2 Source Code Instrumentation . .8 2.3.3 Meta-circular Interpreter . .9 2.4 Correctness and Reliability . .9 2.4.1 Code Smells and Bad Coding Practices . 10 2.4.2 Program Repair . 11 2.4.3 Cross-browser Testing . 11 2.5 Performance . 12 2.5.1 Just-in-time Compilation . 12 2.5.2 Performance Analysis and Proling . 12 2.6 Security . 13 2.6.1 Node.js Security Analysis . 13 i 2.6.2 Manual Security Inspection . 14 2.6.3 Blacklist-based Static Checking Tools . 14 2.6.4 Runtime Monitoring Tools . 14 3 JavaScript Instrumentation 15 3.1 Dynamic Analysis and Instrumentation . 15 3.2 Jalangi Instrumentation Framework . 16 3.3 NodeSec Instrumentation Framework . 22 3.3.1 Node.js Background . 23 3.3.2 Dynamic Instrumentation Overview . 23 3.3.3 Intercepting and Monitoring Built-in System Functions . 24 3.3.4 Instrumentation to Wrap Asynchronous Callbacks. 26 3.3.5 Sandbox . 27 3.4 Rules, Events, and Runtime Patterns . 29 4 Checking Correctness Issues 31 4.1 Introduction . 31 4.2 Approach . 34 4.2.1 Rules, Events, and Runtime Patterns . 34 4.2.2 Problems Related to Inheritance . 36 4.2.3 Problems Related to Types . 38 4.2.4 Problems Related to Language Misuse . 40 4.2.5 Problems Related to API Misuse . 42 4.2.6 Problems Related to Uncommon Values . 44 4.3 Implementation . 45 4.4 Evaluation . 45 4.4.1 Experimental Setup . 46 4.4.2 Dynamic versus Static Checking . 46 4.4.3 Code Quality versus Web Site Popularity . 50 4.4.4 Performance of the Analysis . 50 4.4.5 Examples of Detected Problems . 50 4.4.6 Threats to Validity . 54 ii 4.5 Conclusion . 54 5 Checking Performance Issues 55 5.1 Introduction . 55 5.2 Approach . 57 5.2.1 Framework Overview . 57 5.2.2 Formalization of Prolers . 58 5.2.3 Patterns and Prolers . 59 5.2.4 Sampling . 68 5.3 Implementation . 69 5.4 Evaluation . 70 5.4.1 Experimental Methodology . 70 5.4.2 Prevalence of JIT Unfriendliness . 71 5.4.3 Proling JIT-Unfriendly Code Locations . 71 5.4.4 Runtime Overhead . 76 5.5 Conclusion . 76 6 Checking Security Issues 77 6.1 Introduction . 77 6.2 Background . 79 6.3 Overview . 79 6.3.1 Motivation behind Behavior-driven Study . 81 6.3.2 Identifying Suspicious Behaviors . 81 6.3.3 Dynamically Analyzing an Example . 82 6.4 Suspicious Behaviors . 83 6.4.1 File System Interaction . 84 6.4.2 Network Interaction . 85 6.4.3 Shell Interaction . 85 6.4.4 Ad hoc Attacks/Vulnerabilities . 86 6.4.5 Memory and CPU Monitoring . 86 6.4.6 Package Installation & NPM Scripts . 87 6.5 Implementation . 87 iii 6.5.1 Dynamic Instrumentation . 88 6.5.2 Virtual Machine . 90 6.5.3 Dynamic Analysis . 90 6.6 Empirical Study . 92 6.6.1 Directory Traversal . 97 6.6.2 Backdoor . 97 6.6.3 Virus . 98 6.6.4 Prank & Rockstar . 98 6.6.5 Denial-of-Service Attack . 99 6.6.6 Package Overwriting . 99 6.6.7 Unauthorized Access . 99 6.6.8 Privacy Issues . 100 6.6.9 File Overwrite Attack . 101 6.6.10 Runtime Install & Insecure Download . 101 6.6.11 Violation of Security Practices . 101 6.6.12 Known Vulnerabilities . 102 6.7 Conclusion . 103 7 Limitations 104 8 Summary 106 Bibliography 107 iv List of Figures 3.1 Overview of.
Load more

Recommended publications
  • Differential Fuzzing the Webassembly
    Master’s Programme in Security and Cloud Computing Differential Fuzzing the WebAssembly Master’s Thesis Gilang Mentari Hamidy MASTER’S THESIS Aalto University - EURECOM MASTER’STHESIS 2020 Differential Fuzzing the WebAssembly Fuzzing Différentiel le WebAssembly Gilang Mentari Hamidy This thesis is a public document and does not contain any confidential information. Cette thèse est un document public et ne contient aucun information confidentielle. Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Technology. Antibes, 27 July 2020 Supervisor: Prof. Davide Balzarotti, EURECOM Co-Supervisor: Prof. Jan-Erik Ekberg, Aalto University Copyright © 2020 Gilang Mentari Hamidy Aalto University - School of Science EURECOM Master’s Programme in Security and Cloud Computing Abstract Author Gilang Mentari Hamidy Title Differential Fuzzing the WebAssembly School School of Science Degree programme Master of Science Major Security and Cloud Computing (SECCLO) Code SCI3084 Supervisor Prof. Davide Balzarotti, EURECOM Prof. Jan-Erik Ekberg, Aalto University Level Master’s thesis Date 27 July 2020 Pages 133 Language English Abstract WebAssembly, colloquially known as Wasm, is a specification for an intermediate representation that is suitable for the web environment, particularly in the client-side. It provides a machine abstraction and hardware-agnostic instruction sets, where a high-level programming language can target the compilation to the Wasm instead of specific hardware architecture. The JavaScript engine implements the Wasm specification and recompiles the Wasm instruction to the target machine instruction where the program is executed. Technically, Wasm is similar to a popular virtual machine bytecode, such as Java Virtual Machine (JVM) or Microsoft Intermediate Language (MSIL).
    [Show full text]
  • Interaction Between Web Browsers and Script Engines
    IT 12 058 Examensarbete 45 hp November 2012 Interaction between web browsers and script engines Xiaoyu Zhuang Institutionen för informationsteknologi Department of Information Technology Abstract Interaction between web browser and the script engine Xiaoyu Zhuang Teknisk- naturvetenskaplig fakultet UTH-enheten Web browser plays an important part of internet experience and JavaScript is the most popular programming language as a client side script to build an active and Besöksadress: advance end user experience. The script engine which executes JavaScript needs to Ångströmlaboratoriet Lägerhyddsvägen 1 interact with web browser to get access to its DOM elements and other host objects. Hus 4, Plan 0 Browser from host side needs to initialize the script engine and dispatch script source code to the engine side. Postadress: This thesis studies the interaction between the script engine and its host browser. Box 536 751 21 Uppsala The shell where the engine address to make calls towards outside is called hosting layer. This report mainly discussed what operations could appear in this layer and Telefon: designed testing cases to validate if the browser is robust and reliable regarding 018 – 471 30 03 hosting operations. Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student Handledare: Elena Boris Ämnesgranskare: Justin Pearson Examinator: Lisa Kaati IT 12 058 Tryckt av: Reprocentralen ITC Contents 1. Introduction................................................................................................................................
    [Show full text]
  • Machine Learning in the Browser
    Machine Learning in the Browser The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:38811507 Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA Machine Learning in the Browser a thesis presented by Tomas Reimers to The Department of Computer Science in partial fulfillment of the requirements for the degree of Bachelor of Arts in the subject of Computer Science Harvard University Cambridge, Massachusetts March 2017 Contents 1 Introduction 3 1.1 Background . .3 1.2 Motivation . .4 1.2.1 Privacy . .4 1.2.2 Unavailable Server . .4 1.2.3 Simple, Self-Contained Demos . .5 1.3 Challenges . .5 1.3.1 Performance . .5 1.3.2 Poor Generality . .7 1.3.3 Manual Implementation in JavaScript . .7 2 The TensorFlow Architecture 7 2.1 TensorFlow's API . .7 2.2 TensorFlow's Implementation . .9 2.3 Portability . .9 3 Compiling TensorFlow into JavaScript 10 3.1 Motivation to Compile . 10 3.2 Background on Emscripten . 10 3.2.1 Build Process . 12 3.2.2 Dependencies . 12 3.2.3 Bitness Assumptions . 13 3.2.4 Concurrency Model . 13 3.3 Experiences . 14 4 Results 15 4.1 Benchmarks . 15 4.2 Library Size . 16 4.3 WebAssembly . 17 5 Developer Experience 17 5.1 Universal Graph Runner .
    [Show full text]
  • Executable Code Is Not the Proper Subject of Copyright Law a Retrospective Criticism of Technical and Legal Naivete in the Apple V
    Executable Code is Not the Proper Subject of Copyright Law A retrospective criticism of technical and legal naivete in the Apple V. Franklin case Matthew M. Swann, Clark S. Turner, Ph.D., Department of Computer Science Cal Poly State University November 18, 2004 Abstract: Copyright was created by government for a purpose. Its purpose was to be an incentive to produce and disseminate new and useful knowledge to society. Source code is written to express its underlying ideas and is clearly included as a copyrightable artifact. However, since Apple v. Franklin, copyright has been extended to protect an opaque software executable that does not express its underlying ideas. Common commercial practice involves keeping the source code secret, hiding any innovative ideas expressed there, while copyrighting the executable, where the underlying ideas are not exposed. By examining copyright’s historical heritage we can determine whether software copyright for an opaque artifact upholds the bargain between authors and society as intended by our Founding Fathers. This paper first describes the origins of copyright, the nature of software, and the unique problems involved. It then determines whether current copyright protection for the opaque executable realizes the economic model underpinning copyright law. Having found the current legal interpretation insufficient to protect software without compromising its principles, we suggest new legislation which would respect the philosophy on which copyright in this nation was founded. Table of Contents INTRODUCTION................................................................................................. 1 THE ORIGIN OF COPYRIGHT ........................................................................... 1 The Idea is Born 1 A New Beginning 2 The Social Bargain 3 Copyright and the Constitution 4 THE BASICS OF SOFTWARE ..........................................................................
    [Show full text]
  • Static Analysis the Workhorse of a End-To-End Securitye Testing Strategy
    Static Analysis The Workhorse of a End-to-End Securitye Testing Strategy Achim D. Brucker [email protected] http://www.brucker.uk/ Department of Computer Science, The University of Sheffield, Sheffield, UK Winter School SECENTIS 2016 Security and Trust of Next Generation Enterprise Information Systems February 8–12, 2016, Trento, Italy Static Analysis: The Workhorse of a End-to-End Securitye Testing Strategy Abstract Security testing is an important part of any security development lifecycle (SDL) and, thus, should be a part of any software (development) lifecycle. Still, security testing is often understood as an activity done by security testers in the time between “end of development” and “offering the product to customers.” Learning from traditional testing that the fixing of bugs is the more costly the later it is done in development, security testing should be integrated, as early as possible, into the daily development activities. The fact that static analysis can be deployed as soon as the first line of code is written, makes static analysis the right workhorse to start security testing activities. In this lecture, I will present a risk-based security testing strategy that is used at a large European software vendor. While this security testing strategy combines static and dynamic security testing techniques, I will focus on static analysis. This lecture provides a introduction to the foundations of static analysis as well as insights into the challenges and solutions of rolling out static analysis to more than 20000 developers, distributed across the whole world. A.D. Brucker The University of Sheffield Static Analysis February 8–12., 2016 2 Today: Background and how it works ideally Tomorrow: (Ugly) real world problems and challenges (or why static analysis is “undecideable” in practice) Our Plan A.D.
    [Show full text]
  • Javascript API Deprecation in the Wild: a First Assessment
    JavaScript API Deprecation in the Wild: A First Assessment Romulo Nascimento, Aline Brito, Andre Hora, Eduardo Figueiredo Department of Computer Science Federal University of Minas Gerais, Brazil romulonascimento, alinebrito, andrehora,figueiredo @dcc.ufmg.br { } Abstract—Building an application using third-party libraries of our knowledge, there are no detailed studies regarding API is a common practice in software development. As any other deprecation in the JavaScript ecosystem. software system, code libraries and their APIs evolve over JavaScript has become extremely popular over the last years. time. In order to help version migration and ensure backward According to the Stack Overflow 2019 Developer Survey1, compatibility, a recommended practice during development is to deprecate API. Although studies have been conducted to JavaScript is the most popular programming language in this investigate deprecation in some programming languages, such as platform for the seventh consecutive year. GitHub also reports Java and C#, there are no detailed studies on API deprecation that JavaScript is the most popular language in terms of unique in the JavaScript ecosystem. This paper provides an initial contributors to both public and private repositories2. The npm assessment of API deprecation in JavaScript by analyzing 50 platform, the largest JavaScript package manager, states on popular software projects. Initial results suggest that the use of 3 deprecation mechanisms in JavaScript packages is low. However, their latest survey that 99% of JavaScript developers rely on wefindfive different ways that developers use to deprecate API npm to ease the management of their project dependencies. in the studied projects. Among these solutions, deprecation utility This survey also points out the massive growth in npm usage (i.e., any sort of function specially written to aid deprecation) and that started about 5 years ago.
    [Show full text]
  • Studying the Real World Today's Topics
    Studying the real world Today's topics Free and open source software (FOSS) What is it, who uses it, history Making the most of other people's software Learning from, using, and contributing Learning about your own system Using tools to understand software without source Free and open source software Access to source code Free = freedom to use, modify, copy Some potential benefits Can build for different platforms and needs Development driven by community Different perspectives and ideas More people looking at the code for bugs/security issues Structure Volunteers, sponsored by companies Generally anyone can propose ideas and submit code Different structures in charge of what features/code gets in Free and open source software Tons of FOSS out there Nearly everything on myth Desktop applications (Firefox, Chromium, LibreOffice) Programming tools (compilers, libraries, IDEs) Servers (Apache web server, MySQL) Many companies contribute to FOSS Android core Apple Darwin Microsoft .NET A brief history of FOSS 1960s: Software distributed with hardware Source included, users could fix bugs 1970s: Start of software licensing 1974: Software is copyrightable 1975: First license for UNIX sold 1980s: Popularity of closed-source software Software valued independent of hardware Richard Stallman Started the free software movement (1983) The GNU project GNU = GNU's Not Unix An operating system with unix-like interface GNU General Public License Free software: users have access to source, can modify and redistribute Must share modifications under same
    [Show full text]
  • Chapter 1 Introduction to Computers, Programs, and Java
    Chapter 1 Introduction to Computers, Programs, and Java 1.1 Introduction • The central theme of this book is to learn how to solve problems by writing a program . • This book teaches you how to create programs by using the Java programming languages . • Java is the Internet program language • Why Java? The answer is that Java enables user to deploy applications on the Internet for servers , desktop computers , and small hand-held devices . 1.2 What is a Computer? • A computer is an electronic device that stores and processes data. • A computer includes both hardware and software. o Hardware is the physical aspect of the computer that can be seen. o Software is the invisible instructions that control the hardware and make it work. • Computer programming consists of writing instructions for computers to perform. • A computer consists of the following hardware components o CPU (Central Processing Unit) o Memory (Main memory) o Storage Devices (hard disk, floppy disk, CDs) o Input/Output devices (monitor, printer, keyboard, mouse) o Communication devices (Modem, NIC (Network Interface Card)). Bus Storage Communication Input Output Memory CPU Devices Devices Devices Devices e.g., Disk, CD, e.g., Modem, e.g., Keyboard, e.g., Monitor, and Tape and NIC Mouse Printer FIGURE 1.1 A computer consists of a CPU, memory, Hard disk, floppy disk, monitor, printer, and communication devices. CMPS161 Class Notes (Chap 01) Page 1 / 15 Kuo-pao Yang 1.2.1 Central Processing Unit (CPU) • The central processing unit (CPU) is the brain of a computer. • It retrieves instructions from memory and executes them.
    [Show full text]
  • Some Preliminary Implications of WTO Source Code Proposala INTRODUCTION
    Some preliminary implications of WTO source code proposala INTRODUCTION ............................................................................................................................................... 1 HOW THIS IS TRIMS+ ....................................................................................................................................... 3 HOW THIS IS TRIPS+ ......................................................................................................................................... 3 WHY GOVERNMENTS MAY REQUIRE TRANSFER OF SOURCE CODE .................................................................. 4 TECHNOLOGY TRANSFER ........................................................................................................................................... 4 AS A REMEDY FOR ANTICOMPETITIVE CONDUCT ............................................................................................................. 4 TAX LAW ............................................................................................................................................................... 5 IN GOVERNMENT PROCUREMENT ................................................................................................................................ 5 WHY GOVERNMENTS MAY REQUIRE ACCESS TO SOURCE CODE ...................................................................... 5 COMPETITION LAW .................................................................................................................................................
    [Show full text]
  • Assignment of Master's Thesis
    ASSIGNMENT OF MASTER’S THESIS Title: WebAssembly Approach to Client-side Web Development using Blazor Framework Student: Bc. Matěj Lang Supervisor: Ing. Marek Skotnica Study Programme: Informatics Study Branch: Web and Software Engineering Department: Department of Software Engineering Validity: Until the end of summer semester 2019/20 Instructions The majority of applications we use every day shifted from the desktop to the web. And with this transition, there was an explosion of approaches to the client-side development. The most recent advancement is a WebAssembly technology which allows executing low-level code in a web browser. A goal of this thesis is to create a proof-of-concept application using this technology and evaluate its strengths and weaknesses. Steps to take: Review the WebAssembly technology and the Blazor framework. Compare Blazor to the state-of-the-art client-side web development approaches. Design and create a proof-of-concept application in Blazor. Evaluate Blazor's strengths and weaknesses and its readiness to develop modern web applications. References Will be provided by the supervisor. Ing. Michal Valenta, Ph.D. doc. RNDr. Ing. Marcel Jiřina, Ph.D. Head of Department Dean Prague December 10, 2018 Czech Technical University in Prague Faculty of Information Technology Department of Web and Software Engineer- ing Master's thesis WebAssembly Approach to Client-side Web Development using Blazor Framework Bc. MatˇejLang Supervisor: Ing. Marek Skotnica 7th May 2019 Acknowledgements In this place I want to thank Bc. Katerina Cern´ıkov´aandˇ Mgr. Jakub Klement for language corrections. I want to thank my master thesis supervisor - Ing. Marek Skotnica for his patience and advice.
    [Show full text]
  • Precise and Scalable Static Program Analysis of NASA Flight Software
    Precise and Scalable Static Program Analysis of NASA Flight Software G. Brat and A. Venet Kestrel Technology NASA Ames Research Center, MS 26912 Moffett Field, CA 94035-1000 650-604-1 105 650-604-0775 brat @email.arc.nasa.gov [email protected] Abstract-Recent NASA mission failures (e.g., Mars Polar Unfortunately, traditional verification methods (such as Lander and Mars Orbiter) illustrate the importance of having testing) cannot guarantee the absence of errors in software an efficient verification and validation process for such systems. Therefore, it is important to build verification tools systems. One software error, as simple as it may be, can that exhaustively check for as many classes of errors as cause the loss of an expensive mission, or lead to budget possible. Static program analysis is a verification technique overruns and crunched schedules. Unfortunately, traditional that identifies faults, or certifies the absence of faults, in verification methods cannot guarantee the absence of errors software without having to execute the program. Using the in software systems. Therefore, we have developed the CGS formal semantic of the programming language (C in our static program analysis tool, which can exhaustively analyze case), this technique analyses the source code of a program large C programs. CGS analyzes the source code and looking for faults of a certain type. We have developed a identifies statements in which arrays are accessed out Of static program analysis tool, called C Global Surveyor bounds, or, pointers are used outside the memory region (CGS), which can analyze large C programs for embedded they should address.
    [Show full text]
  • Static Program Analysis Via 3-Valued Logic
    Static Program Analysis via 3-Valued Logic ¡ ¢ £ Thomas Reps , Mooly Sagiv , and Reinhard Wilhelm ¤ Comp. Sci. Dept., University of Wisconsin; [email protected] ¥ School of Comp. Sci., Tel Aviv University; [email protected] ¦ Informatik, Univ. des Saarlandes;[email protected] Abstract. This paper reviews the principles behind the paradigm of “abstract interpretation via § -valued logic,” discusses recent work to extend the approach, and summarizes on- going research aimed at overcoming remaining limitations on the ability to create program- analysis algorithms fully automatically. 1 Introduction Static analysis concerns techniques for obtaining information about the possible states that a program passes through during execution, without actually running the program on specific inputs. Instead, static-analysis techniques explore a program’s behavior for all possible inputs and all possible states that the program can reach. To make this feasible, the program is “run in the aggregate”—i.e., on abstract descriptors that repre- sent collections of many states. In the last few years, researchers have made important advances in applying static analysis in new kinds of program-analysis tools for identi- fying bugs and security vulnerabilities [1–7]. In these tools, static analysis provides a way in which properties of a program’s behavior can be verified (or, alternatively, ways in which bugs and security vulnerabilities can be detected). Static analysis is used to provide a safe answer to the question “Can the program reach a bad state?” Despite these successes, substantial challenges still remain. In particular, pointers and dynamically-allocated storage are features of all modern imperative programming languages, but their use is error-prone: ¨ Dereferencing NULL-valued pointers and accessing previously deallocated stor- age are two common programming mistakes.
    [Show full text]