DOCSLIB.ORG

Improving the Quality of Error-Handling Code in Systems Software Using Function-Local Information Suman Saha

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Improving the Quality of Error-Handling Code in Systems Software using Function-Local Information Suman Saha To cite this version: Suman Saha. Improving the Quality of Error-Handling Code in Systems Software using Function- Local Information. Programming Languages [cs.PL]. Université Pierre et Marie Curie - Paris VI, 2013. English. tel-00937807 HAL Id: tel-00937807 https://tel.archives-ouvertes.fr/tel-00937807 Submitted on 28 Jan 2014 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. THÈSE DE DOCTORAT DE l’UNIVERSITÉ PIERRE ET MARIE CURIE Spécialité Informatique École doctorale Informatique, Télécommunications et Électronique (Paris) Suman SAHA Pour obtenir le grade de DOCTEUR de l’UNIVERSITÉ PIERRE ET MARIE CURIE Sujet de la thèse : Improving the Quality of Error-Handling Code in Systems Software using Function-Local Information soutenue le 25 mars 2013 M. Gilles MULLER Directeur de thèse Mme. Julia LAWALL Directeur de thèse Mme. Sandrine BLAZY Rapporteur M. Laurent REVÉILLÈRE Rapporteur M. Olaf SPINCZYK Examinateur M. Yannis SMARAGDAKIS Examinateur M. Fabrice KORDON Examinateur ii Acknowledgements First and foremost, I would like to express my gratitude to my both advisors Gilles Muller and Julia Lawall, for their essential guidances and insight throughout my graduate career. Their supports and encouragements throughout the thesis have been very helpful, and without our many fruitful discussions the result would surely not have been as good. I would also like to thank my thesis jury. Both of the thesis reporters, Mme. Sandrine Blazy and M. Laurent Revéillère have spent their valuable time to improve the thesis quality. I am really thankful to them. My sincere and warm thanks go to all my colleagues at Regal group in LIP6 Lab for their inspirations and helpful comments during my thesis. I especially thank to Gaël Thomas, Jean-Pierre Lozi, Brice Berna and Lokesh Gidra for devoting some of their precious time to help me at the some points of my work. Special thanks to my friend, Mahfuza Farooque for encouraging and supporting me at every stage during my studies. Needless to say, my family deserve a great deal of credit for my development. I thank my parents and younger brother for all their love and supports. Finally, I would like to thank God for giving me ability to do this work. Abstract Adequate error-handling code is essential to the reliability of any systems software. On an er- ror, such code is responsible for releasing acquired resources to restore the system to a viable state. Omitting such operations leads not only to memory leaks, but also to system crashes and deadlocks. The C language does not provide any abstractions for exception handling or other forms of error handling, leaving programmers to devise their own conventions for detecting and handling errors. The Linux coding style guidelines suggest placing error handling code at the end of each function, where it can be reached by gotos whenever an error is detected. This coding style has the advantage of putting all of the error-handling code in one place, which eases understanding and maintenance, and reduces code duplication. Nevertheless, this coding style is not always applied. In the first part of the thesis, we propose an automatic program transformation that transforms error-handling code into this style. We have implemented this algorithm as a tool and have applied this tool to five directories (drivers, fs, net, arch, and sound) in Linux 3.6 kernel source code as well as to five widely used open-source systems software projects: PostgreSQL, Apache, Wine, Python, and PHP. This tool successfully converts 22% of the conditionals containing state-restoring error-handling code that have the scope to merge code into one, from the basic strategy to the goto-based strategy. Even when error handling code is structured according to the Linux coding style guidelines, the management of the releasing of allocated resources remains a continual problem in ensuring the ro- bustness of systems software. Finding such faults is very challenging due to the difficulty of system- atically reproducing system errors and the diversity of system resources and their associated resource release operations. To address these issues, over 10 years of research has focused on macroscopic approaches that globally scan a code base for common resource-release operations. Such approaches are notorious for their high rates of false positives, while at the same time, in practice, they leave many faults undetected. In the second part of the thesis, we propose a novel microscopic approach to finding resource- release faults in systems software, taking into account such software’s diversity of resource types and resource-release operations. Rather than generalizing from the results of a complete scan of the source code, our approach achieves precision and scalability by focusing on the error-handling code of each function. Using a tool, Hector, that we have developed based on this approach, we have found 485 faults in 19 different C systems software projects, including Linux, Python, and Apache, with a false positive rate of 23%, well below the 30% that has been reported to be acceptable to developers. Some of these faults are exploitable by an unprivileged malicious user, making it possible to crash the entire system. vii Contents 1 Introduction 1 1.1 Refactoring Programming Code . .2 1.2 Improving the Quality of Error-Handling Code . .4 1.3 Outline of the thesis . .7 2 Background 9 2.1 Bugs in Systems Software . .9 2.2 Terminology . 10 2.3 Considered Software . 11 2.4 Error handling in Systems Software . 14 2.5 State of the Art . 18 2.5.1 Refactoring C Code . 18 2.5.2 Finding Faults in Source Code . 19 2.5.3 Improving Error-handling Code . 27 2.6 Survey on Faults in Linux . 30 3 Improving Structure of Error Handling Code 33 3.1 Summary . 33 3.2 Motivation and Background . 34 3.2.1 Motivating Examples . 34 3.2.2 Analysis . 36 3.3 Transformation Algorithm . 39 3.3.1 Identifying Error-Handling Code (step 1) . 39 3.3.2 Partition (step 2a) . 46 3.3.3 Filtering (step 2b) . 48 3.3.4 Classification and transformation (step 3) . 48 3.4 Evaluation . 52 3.4.1 An example from the Linux kernel. 52 3.4.2 The impact of filtering. 54 3.4.3 Branch classification. 56 3.4.4 Branch transformation. 58 3.4.5 Code sharing. 58 3.5 Conclusion . 59 4 Finding Faults in Error Handling Code 61 viii Contents 4.1 Summary . 62 4.2 Motivation . 62 4.2.1 Linux resource-release omission faults . 62 4.3 Systems error-handling code . 65 4.3.1 Amount of code containing error-handling code . 65 4.3.2 Role of code containing error-handling code . 66 4.3.3 Kinds of errors encountered . 66 4.4 Algorithm . 67 4.5 Implementation . 70 4.5.1 Preprocessing phase . 70 4.5.2 Instantiation of the algorithm . 71 4.5.3 Formal Description of the Algorithm . 73 4.6 Ranking reports . 76 4.7 Experimenting with Hector . 77 4.7.1 Found faults . 77 4.7.2 Comparison to specification mining. 78 4.7.3 Comparison to faults fixed in Linux. 79 4.7.4 Impact of the detected faults . 80 4.7.5 False positives . 82 4.7.6 False negatives . 84 4.7.7 The benefits of the analysis features . 84 4.7.8 Scalability . 86 4.7.9 Threats to validity . 87 4.8 Conclusion . 87 5 Conclusion and Future Work 89 5.1 Conclusion . 89 5.2 Limitations and Future Work . 90 5.2.1 Relax the need for exemplars . 90 5.2.2 Other memory related bugs . 90 5.2.3 Fixing bugs . 90 5.2.4 Finding shared variables . 92 5.2.5 Bugs in web applications . 92 5.3 Summary of Contributions . 94 107 1 Chapter 1 Introduction Contents 1.1 Refactoring Programming Code . .2 1.2 Improving the Quality of Error-Handling Code . .4 1.3 Outline of the thesis . .7 Any computing system may encounter errors, such as inappropriate requests from supported ap- plications, or unexpected behavior from malfunctioning or misconfigured hardware. If the system’s software, such as its operating system, programming-language runtime, or web server, does not re- cover from these errors correctly, they may lead to more serious failures such as a crash or a vulner- ability to an attack by a malicious user. Therefore, correct error recovery is essential when a system supports long-running or critical services. Indeed, the ability to recover from errors has long been viewed as a cornerstone of system reliability [55], and much of systems code is concerned with error detection and handling. For example, 48% of Linux 2.6.34 driver code is found in functions that handle at least one error.1 Systems code is written in C, which unlike more modern programming languages such as Java, does not provide any specific abstractions for resource management or error-handling code. Error handling code is responsible for detecting the failure of an operation, releasing allocated resources to restore the system to a consistent state, and returning an appropriate error indicator to the calling function.
Recommended publications
  • Assignment 6: Subtyping and Bidirectional Typing

    Assignment 6: Subtyping and Bidirectional Typing

    Assignment 6: Subtyping and Bidirectional Typing 15-312: Foundations of Programming Languages Joshua Dunfield ([email protected]) Out: Thursday, October 24, 2002 Due: Thursday, November 7 (11:59:59 pm) 100 points total + (up to) 20 points extra credit 1 Introduction In this assignment, you will implement a bidirectional typechecker for MinML with , , +, 1, 0, , , and subtyping with base types int and float. ! ∗ 8 9 Note: In the .sml files, most changes from Assignment 4 are indicated like this: (* new asst6 code: *) ... (* end asst6 code *) 2 New in this assignment Some things have become obsolete (and have either been removed or left • in a semi-supported state). Exceptions and continuations are no longer “officially” supported. One can now (and sometimes must!) write type annotations e : τ. The • abstract syntax constructor is called Anno. The lexer supports shell-style comments in .mml source files: any line • beginning with # is ignored. There are now two valid syntaxes for functions, the old syntax fun f (x:t1):t2 is e end • and a new syntax fun f(x) is e end. Note the lack of type anno- tations. The definition of the abstract syntax constructor Fun has been changed; its arguments are now just bindings for f and x and the body. It no longer takes two types. 1 The old syntax fun f(x:t1):t2 is e end is now just syntactic sugar, transformed by the parser into fun f(x) is e end : t1 -> t2. There are floating point numbers, written as in SML. There is a new set of • arithmetic operators +., -., *., ˜.
  • (901133) Instructor: Eng

    (901133) Instructor: Eng

    home Al-Albayt University Computer Science Department C++ Programming 1 (901133) Instructor: Eng. Rami Jaradat [email protected] 1 home Subjects 1. Introduction to C++ Programming 2. Control Structures 3. Functions 4. Arrays 5. Pointers 6. Strings 2 home 1 - Introduction to C++ Programming 3 home What is computer? • Computers are programmable devices capable of performing computations and making logical decisions. • Computers can store, retrieve, and process data according to a list of instructions • Hardware is the physical part of the compute: keyboard, screen, mouse, disks, memory, and processing units • Software is a collection of computer programs, procedures and documentation that perform some tasks on a computer system 4 home Computer Logical Units • Input unit – obtains information (data) from input devices • Output unit – outputs information to output device or to control other devices. • Memory unit – Rapid access, low capacity, stores information • Secondary storage unit – cheap, long-term, high-capacity storage, stores inactive programs • Arithmetic and logic unit (ALU) – performs arithmetic calculations and logic decisions • Central processing unit (CPU): – supervises and coordinates the other sections of the computer 5 home Computer language • Machine languages: machine dependent, it consists of strings of numbers giving machine specific instructions: +1300042774 +1400593419 +1200274027 • Assembly languages: English-like abbreviations representing elementary operations, assemblers convert assembly language to machine
  • Semantic Patches for Java Program Transformation

    Semantic Patches for Java Program Transformation

    Semantic Patches for Java Program Transformation Hong Jin Kang School of Information Systems, Singapore Management University, Singapore Ferdian Thung School of Information Systems, Singapore Management University, Singapore Julia Lawall Sorbonne Université/Inria/LIP6, France Gilles Muller Sorbonne Université/Inria/LIP6, France Lingxiao Jiang School of Information Systems, Singapore Management University, Singapore David Lo School of Information Systems, Singapore Management University, Singapore Abstract Developing software often requires code changes that are widespread and applied to multiple locations. There are tools for Java that allow developers to specify patterns for program matching and source- to-source transformation. However, to our knowledge, none allows for transforming code based on its control-flow context. We prototype Coccinelle4J, an extension to Coccinelle, which is a program transformation tool designed for widespread changes in C code, in order to work on Java source code. We adapt Coccinelle to be able to apply scripts written in the Semantic Patch Language (SmPL), a language provided by Coccinelle, to Java source files. As a case study, we demonstrate the utility of Coccinelle4J with the task of API migration. We show 6 semantic patches to migrate from deprecated Android API methods on several open source Android projects. We describe how SmPL can be used to express several API migrations and justify several of our design decisions. 2012 ACM Subject Classification Software and its engineering → Software notations and tools Keywords and phrases Program transformation, Java Digital Object Identifier 10.4230/LIPIcs.ECOOP.2019.22 Category Experience Report Supplement Material ECOOP 2019 Artifact Evaluation approved artifact available at https://dx.doi.org/10.4230/DARTS.5.2.10 Coccinelle4J can be found at https://github.com/kanghj/coccinelle/tree/java Funding This research was supported by the Singapore National Research Foundation (award number: NRF2016-NRF-ANR003) and the ANR ITrans project.
  • Coccinelle: Reducing the Barriers to Modularization in a Large C Code Base

    Coccinelle: Reducing the Barriers to Modularization in a Large C Code Base

    Coccinelle: Reducing the Barriers to Modularization in a Large C Code Base Julia Lawall Inria/LIP6/UPMC/Sorbonne University-Regal Modularity 2014 1 Modularity Wikipedia: Modularity is the degree to which a system's components may be separated and recombined. • A well-designed system (likely) starts with a high degree of modularity. • Modularity must be maintained as a system evolves. • Evolution decisions may be determined by the impact on modularity. Goal: Maintaining modularity should be easy as a system evolves. 2 Modularity and API functions Well designed API functions can improve modularity • Hide module-local variable names. • Hide module-local function protocols. Problem: • The perfect API may not be apparent in the original design. • The software may evolve, making new APIs needed. • Converting to new APIs is hard. 3 Modularity in the Linux kernel ipv4 ipv6 ext4 Net File system library library Kernel btrfs e1000e Driver library ... tun tef6862 4 An improvement in modularity could better isolate functionality in one of these modules. Case study: Memory management in Linux Since Linux 1.0, 1994: • kmalloc: allocate memory • memset: clear memory • kfree: free memory Since Linux 2.6.14, 2006: • kzalloc: allocate memory • kfree: free memory • No separate clearing, but need explicit free. Since Linux 2.6.21, 2007: • devm kzalloc: allocate memory • No explicit free. 5 6 kzalloc platform kzalloc platform devm_kzalloc 800 i2c kzalloc i2c devm_kzalloc 600 calls 400 200 0 2.6.20 2.6.22 2.6.24 2.6.26 2.6.28 2.6.30 2.6.32 2.6.34 2.6.36 2.6.38
  • Explicitly Implicifying Explicit Constructors

    Explicitly Implicifying Explicit Constructors

    Explicitly Implicifying explicit Constructors Document number: P1163R0 Date: 2018-08-31 Project: Programming Language C++, Library Working Group Reply-to: Nevin “☺” Liber, [email protected] or [email protected] Table of Contents Revision History ................................................................................................................ 3 P11630R0 .................................................................................................................................... 3 Introduction ....................................................................................................................... 4 Motivation and Scope ....................................................................................................... 5 Impact On the Standard ................................................................................................... 6 Policy .................................................................................................................................. 7 Design Decisions ................................................................................................................ 8 Technical Specifications ................................................................................................... 9 [template.bitset]........................................................................................................................ 10 [bitset.cons] ..............................................................................................................................
  • Inferring Semantic Patches for the Linux Kernel

    Inferring Semantic Patches for the Linux Kernel

    SPINFER: Inferring Semantic Patches for the Linux Kernel Lucas Serrano and Van-Anh Nguyen, Sorbonne University/Inria/LIP6; Ferdian Thung, Lingxiao Jiang, and David Lo, School of Information Systems, Singapore Management University; Julia Lawall and Gilles Muller, Inria/Sorbonne University/LIP6 https://www.usenix.org/conference/atc20/presentation/serrano This paper is included in the Proceedings of the 2020 USENIX Annual Technical Conference. July 15–17, 2020 978-1-939133-14-4 Open access to the Proceedings of the 2020 USENIX Annual Technical Conference is sponsored by USENIX. SPINFER: Inferring Semantic Patches for the Linux Kernel Lucas Serrano Van-Anh Nguyen Sorbonne University/Inria/LIP6 Sorbonne University/Inria/LIP6 Ferdian Thung Lingxiao Jiang School of Information System School of Information System Singapore Management University Singapore Management University David Lo Julia Lawall, Gilles Muller School of Information System Inria/Sorbonne University/LIP6 Singapore Management University Abstract (i.e., diff-like) syntax, enhanced with metavariables to rep- In a large software system such as the Linux kernel, there is resent common but unspecified subterms and notation for a continual need for large-scale changes across many source reasoning about control-flow paths. Given a semantic patch, files, triggered by new needs or refined design decisions. In Coccinelle applies the rules automatically across the code this paper, we propose to ease such changes by suggesting base. Today, Coccinelle is widely adopted by the Linux com- transformation rules to developers, inferred automatically munity: semantic patches are part of the Linux kernel source from a collection of examples. Our approach can help auto- tree, are invokable from the kernel build infrastructure, and mate large-scale changes as well as help understand existing are regularly run by Intel’s Linux kernel 0-day build-testing large-scale changes, by highlighting the various cases that service [10].
  • Automating Patching of Vulnerable Open-Source Software Versions in Application Binaries

    Automating Patching of Vulnerable Open-Source Software Versions in Application Binaries

    Automating Patching of Vulnerable Open-Source Software Versions in Application Binaries Ruian Duan:, Ashish Bijlani:, Yang Ji:, Omar Alrawi:, Yiyuan Xiong˚, Moses Ike:, Brendan Saltaformaggio,: and Wenke Lee: fruian, ashish.bijlani, yang.ji, alrawi, [email protected], [email protected] [email protected], [email protected] : Georgia Institute of Technology, ˚ Peking University Abstract—Mobile application developers rely heavily on open- while ensuring backward compatibility, and test for unin- source software (OSS) to offload common functionalities such tended side-effects. For the Android platform, Google has as the implementation of protocols and media format playback. initiated the App Security Improvement Program (ASIP) [21] Over the past years, several vulnerabilities have been found in to notify developers of vulnerable third-party libraries in popular open-source libraries like OpenSSL and FFmpeg. Mobile use. Unfortunately, many developers, as OSSPolice [15] and applications that include such libraries inherit these flaws, which LibScout [4] show, do not update or patch their application, make them vulnerable. Fortunately, the open-source community is responsive and patches are made available within days. However, which leaves end-users exposed. Android developers mainly mobile application developers are often left unaware of these use Java and C/C++ [1] libraries. While Derr et al. [14] flaws. The App Security Improvement Program (ASIP) isa show that vulnerable Java libraries can be fixed by library- commendable effort by Google to notify application developers level update, their C/C++ counterparts, which contain many of these flaws, but recent work has shown that many developers more documented security bugs in the National Vulnerability do not act on this information.
  • The Cool Reference Manual∗

    The Cool Reference Manual∗

    The Cool Reference Manual∗ Contents 1 Introduction 3 2 Getting Started 3 3 Classes 4 3.1 Features . 4 3.2 Inheritance . 5 4 Types 6 4.1 SELF TYPE ........................................... 6 4.2 Type Checking . 7 5 Attributes 8 5.1 Void................................................ 8 6 Methods 8 7 Expressions 9 7.1 Constants . 9 7.2 Identifiers . 9 7.3 Assignment . 9 7.4 Dispatch . 10 7.5 Conditionals . 10 7.6 Loops . 11 7.7 Blocks . 11 7.8 Let . 11 7.9 Case . 12 7.10 New . 12 7.11 Isvoid . 12 7.12 Arithmetic and Comparison Operations . 13 ∗Copyright c 1995-2000 by Alex Aiken. All rights reserved. 1 8 Basic Classes 13 8.1 Object . 13 8.2 IO ................................................. 13 8.3 Int................................................. 14 8.4 String . 14 8.5 Bool . 14 9 Main Class 14 10 Lexical Structure 14 10.1 Integers, Identifiers, and Special Notation . 15 10.2 Strings . 15 10.3 Comments . 15 10.4 Keywords . 15 10.5 White Space . 15 11 Cool Syntax 17 11.1 Precedence . 17 12 Type Rules 17 12.1 Type Environments . 17 12.2 Type Checking Rules . 18 13 Operational Semantics 22 13.1 Environment and the Store . 22 13.2 Syntax for Cool Objects . 24 13.3 Class definitions . 24 13.4 Operational Rules . 25 14 Acknowledgements 30 2 1 Introduction This manual describes the programming language Cool: the Classroom Object-Oriented Language. Cool is a small language that can be implemented with reasonable effort in a one semester course. Still, Cool retains many of the features of modern programming languages including objects, static typing, and automatic memory management.
  • Generic Immutability and Nullity Types for an Imperative Object-Oriented Programming Language with flexible Initialization

    Generic Immutability and Nullity Types for an Imperative Object-Oriented Programming Language with flexible Initialization

    Generic Immutability and Nullity Types for an imperative object-oriented programming language with flexible initialization James Elford June 21, 2012 Abstract We present a type system for parametric object mutability and ref- erence nullity in an imperative object oriented language. We present a simple but powerful system for generic nullity constraints, and build on previous work to provide safe initialization of objects which is not bound to constructors. The system is expressive enough to handle initialization of cyclic immutable data structures, and to enforce their cyclic nature through the type system. We provide the crucial parts of soundness ar- guments (though the full proof is not yet complete). Our arguments are novel, in that they do not require auxiliary runtime constructs (ghost state) in order to express or demonstrate our desired properties. 2 Contents 1 Introduction 4 1.1 In this document . .5 2 Background 6 2.1 Parametric Types . .6 2.1.1 Static Polymorphism through Templates . .7 2.1.2 Static Polymorphism through Generic Types . 12 2.2 Immutability . 18 2.2.1 Immutability in C++ .................... 19 2.2.2 Immutability in Java and C# ............... 21 2.2.3 An extension to Java's immutability model . 21 2.2.4 Parametric Immutability Constraints . 24 2.3 IGJ: Immutability Generic Java .................. 25 2.4 Nullity . 27 2.5 Areas of commonality . 30 3 Goals 32 4 Existing systems in more detail 34 4.1 The initialization problem . 34 4.2 What do we require from initialization? . 35 4.3 Approaches to initialization . 37 4.4 Delay Types and initialization using stack-local regions .
  • C DEFINES and C++ TEMPLATES Professor Ken Birman

    C DEFINES and C++ TEMPLATES Professor Ken Birman

    Professor Ken Birman C DEFINES AND C++ TEMPLATES CS4414 Lecture 10 CORNELL CS4414 - FALL 2020. 1 COMPILE TIME “COMPUTING” In lecture 9 we learned about const, constexpr and saw that C++ really depends heavily on these Ken’s solution to homework 2 runs about 10% faster with extensive use of these annotations Constexpr underlies the “auto” keyword and can sometimes eliminate entire functions by precomputing their results at compile time. Parallel C++ code would look ugly without normal code structuring. Const and constexpr allow the compiler to see “beyond” that and recognize parallelizable code paths. CORNELL CS4414 - FALL 2020. 2 … BUT HOW FAR CAN WE TAKE THIS IDEA? Today we will look at the concept of programming the compiler using the templating layer of C++ We will see that it is a powerful tool! There are also programmable aspects of Linux, and of the modern hardware we use. By controlling the whole system, we gain speed and predictability while writing elegant, clean code. CORNELL CS4414 - FALL 2020. 3 IDEA MAP FOR TODAY History of generics: #define in C Templates are easy to create, if you stick to basics The big benefit compared to Java is that a template We have seen a number of parameterized is a compile-time construct, whereas in Java a generic types in C++, like std::vector and std::map is a run-time construct. The template language is Turing-complete, but computes These are examples of “templates”. only on types, not data from the program (even when They are like generics in Java constants are provided).
  • Class Notes on Type Inference 2018 Edition Chuck Liang Hofstra University Computer Science

    Class Notes on Type Inference 2018 Edition Chuck Liang Hofstra University Computer Science

    Class Notes on Type Inference 2018 edition Chuck Liang Hofstra University Computer Science Background and Introduction Many modern programming languages that are designed for applications programming im- pose typing disciplines on the construction of programs. In constrast to untyped languages such as Scheme/Perl/Python/JS, etc, and weakly typed languages such as C, a strongly typed language (C#/Java, Ada, F#, etc ...) place constraints on how programs can be written. A type system ensures that programs observe logical structure. The origins of type theory stretches back to the early twentieth century in the work of Bertrand Russell and Alfred N. Whitehead and their \Principia Mathematica." They observed that our language, if not restrained, can lead to unsolvable paradoxes. Specifically, let's say a mathematician defined S to be the set of all sets that do not contain themselves. That is: S = fall A : A 62 Ag Then it is valid to ask the question does S contain itself (S 2 S?). If the answer is yes, then by definition of S, S is one of the 'A's, and thus S 62 S. But if S 62 S, then S is one of those sets that do not contain themselves, and so it must be that S 2 S! This observation is known as Russell's Paradox. In order to avoid this paradox, the language of mathematics (or any language for that matter) must be constrained so that the set S cannot be defined. This is one of many discoveries that resulted from the careful study of language, logic and meaning that formed the foundation of twentieth century analytical philosophy and abstract mathematics, and also that of computer science.
  • C Programming Tutorial

    C Programming Tutorial

    C Programming Tutorial C PROGRAMMING TUTORIAL Simply Easy Learning by tutorialspoint.com tutorialspoint.com i COPYRIGHT & DISCLAIMER NOTICE All the content and graphics on this tutorial are the property of tutorialspoint.com. Any content from tutorialspoint.com or this tutorial may not be redistributed or reproduced in any way, shape, or form without the written permission of tutorialspoint.com. Failure to do so is a violation of copyright laws. This tutorial may contain inaccuracies or errors and tutorialspoint provides no guarantee regarding the accuracy of the site or its contents including this tutorial. If you discover that the tutorialspoint.com site or this tutorial content contains some errors, please contact us at [email protected] ii Table of Contents C Language Overview .............................................................. 1 Facts about C ............................................................................................... 1 Why to use C ? ............................................................................................. 2 C Programs .................................................................................................. 2 C Environment Setup ............................................................... 3 Text Editor ................................................................................................... 3 The C Compiler ............................................................................................ 3 Installation on Unix/Linux ............................................................................