Aliasing Restrictions of C11 Formalized in Coq
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Create Union Variables Difference Between Unions and Structures
Union is a user-defined data type similar to a structure in C programming. How to define a union? We use union keyword to define unions. Here's an example: union car { char name[50]; int price; }; The above code defines a user define data type union car. Create union variables When a union is defined, it creates a user-define type. However, no memory is allocated. To allocate memory for a given union type and work with it, we need to create variables. Here's how we create union variables: union car { char name[50]; int price; } car1, car2, *car3; In both cases, union variables car1, car2, and a union pointer car3 of union car type are created. How to access members of a union? We use . to access normal variables of a union. To access pointer variables, we use ->operator. In the above example, price for car1 can be accessed using car1.price price for car3 can be accessed using car3->price Difference between unions and structures Let's take an example to demonstrate the difference between unions and structures: #include <stdio.h> union unionJob { //defining a union char name[32]; float salary; int workerNo; } uJob; struct structJob { char name[32]; float salary; int workerNo; } sJob; main() { printf("size of union = %d bytes", sizeof(uJob)); printf("\nsize of structure = %d bytes", sizeof(sJob)); } Output size of union = 32 size of structure = 40 Why this difference in size of union and structure variables? The size of structure variable is 40 bytes. It's because: size of name[32] is 32 bytes size of salary is 4 bytes size of workerNo is 4 bytes However, the size of union variable is 32 bytes. -
Using the GNU Compiler Collection (GCC)
Using the GNU Compiler Collection (GCC) Using the GNU Compiler Collection by Richard M. Stallman and the GCC Developer Community Last updated 23 May 2004 for GCC 3.4.6 For GCC Version 3.4.6 Published by: GNU Press Website: www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 59 Temple Place Suite 330 Tel 617-542-5942 Boston, MA 02111-1307 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004 Free Software Foundation, Inc. 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 the Invariant Sections being \GNU General Public License" and \Funding Free Software", the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled \GNU Free Documentation License". (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. i Short Contents Introduction ...................................... 1 1 Programming Languages Supported by GCC ............ 3 2 Language Standards Supported by GCC ............... 5 3 GCC Command Options ......................... -
[Note] C/C++ Compiler Package for RX Family (No.55-58)
RENESAS TOOL NEWS [Note] R20TS0649EJ0100 Rev.1.00 C/C++ Compiler Package for RX Family (No.55-58) Jan. 16, 2021 Overview When using the CC-RX Compiler package, note the following points. 1. Using rmpab, rmpaw, rmpal or memchr intrinsic functions (No.55) 2. Performing the tail call optimization (No.56) 3. Using the -ip_optimize option (No.57) 4. Using multi-dimensional array (No.58) Note: The number following the note is an identification number for the note. 1. Using rmpab, rmpaw, rmpal or memchr intrinsic functions (No.55) 1.1 Applicable products CC-RX V2.00.00 to V3.02.00 1.2 Details The execution result of a program including the intrinsic function rmpab, rmpaw, rmpal, or the standard library function memchr may not be as intended. 1.3 Conditions This problem may arise if all of the conditions from (1) to (3) are met. (1) One of the following calls is made: (1-1) rmpab or __rmpab is called. (1-2) rmpaw or __rmpaw is called. (1-3) rmpal or __rmpal is called. (1-4) memchr is called. (2) One of (1-1) to (1-3) is met, and neither -optimize=0 nor -noschedule option is specified. (1-4) is met, and both -size and -avoid_cross_boundary_prefetch (Note 1) options are specified. (3) Memory area that overlaps with the memory area (Note2) read by processing (1) is written in a single function. (This includes a case where called function processing is moved into the caller function by inline expansion.) Note 1: This is an option added in V2.07.00. -
Exploring C Semantics and Pointer Provenance
Exploring C Semantics and Pointer Provenance KAYVAN MEMARIAN, University of Cambridge VICTOR B. F. GOMES, University of Cambridge BROOKS DAVIS, SRI International STEPHEN KELL, University of Cambridge ALEXANDER RICHARDSON, University of Cambridge ROBERT N. M. WATSON, University of Cambridge PETER SEWELL, University of Cambridge The semantics of pointers and memory objects in C has been a vexed question for many years. C values cannot be treated as either purely abstract or purely concrete entities: the language exposes their representations, 67 but compiler optimisations rely on analyses that reason about provenance and initialisation status, not just runtime representations. The ISO WG14 standard leaves much of this unclear, and in some respects differs with de facto standard usage — which itself is difficult to investigate. In this paper we explore the possible source-language semantics for memory objects and pointers, in ISO C and in C as it is used and implemented in practice, focussing especially on pointer provenance. We aim to, as far as possible, reconcile the ISO C standard, mainstream compiler behaviour, and the semantics relied on by the corpus of existing C code. We present two coherent proposals, tracking provenance via integers and not; both address many design questions. We highlight some pros and cons and open questions, and illustrate the discussion with a library of test cases. We make our semantics executable as a test oracle, integrating it with the Cerberus semantics for much of the rest of C, which we have made substantially more complete and robust, and equipped with a web-interface GUI. This allows us to experimentally assess our proposals on those test cases. -
Timur Doumler @Timur Audio
Type punning in modern C++ version 1.1 Timur Doumler @timur_audio C++ Russia 30 October 2019 Image: ESA/Hubble Type punning in modern C++ 2 How not to do type punning in modern C++ 3 How to write portable code that achieves the same effect as type punning in modern C++ 4 How to write portable code that achieves the same effect as type punning in modern C++ without causing undefined behaviour 5 6 7 � 8 � (�) 9 10 11 12 struct Widget { virtual void doSomething() { printf("Widget"); } }; struct Gizmo { virtual void doSomethingCompletelyDifferent() { printf("Gizmo"); } }; int main() { Gizmo g; Widget* w = (Widget*)&g; w->doSomething(); } Example from Luna @lunasorcery 13 struct Widget { virtual void doSomething() { printf("Widget"); } }; struct Gizmo { virtual void doSomethingCompletelyDifferent() { printf("Gizmo"); } }; int main() { Gizmo g; Widget* w = (Widget*)&g; w->doSomething(); } Example from Luna @lunasorcery 14 15 Don’t use C-style casts. 16 struct Widget { virtual void doSomething() { printf("Widget"); } }; struct Gizmo { virtual void doSomethingCompletelyDifferent() { printf("Gizmo"); } }; int main() { Gizmo g; Widget* w = (Widget*)&g; w->doSomething(); } Example from Luna @lunasorcery 17 18 19 20 float F0 00 80 01 int F0 00 80 01 21 float F0 00 80 01 int F0 00 80 01 float F0 00 80 01 char* std::byte* F0 00 80 01 22 float F0 00 80 01 int F0 00 80 01 float F0 00 80 01 char* std::byte* F0 00 80 01 Widget F0 00 80 01 01 BD 83 E3 float[2] F0 00 80 01 01 BD 83 E3 23 float F0 00 80 01 int F0 00 80 01 float F0 00 80 01 char* std::byte* -
Effective Types: Examples (P1796R0) 2 3 4 PETER SEWELL, University of Cambridge 5 KAYVAN MEMARIAN, University of Cambridge 6 VICTOR B
1 Effective types: examples (P1796R0) 2 3 4 PETER SEWELL, University of Cambridge 5 KAYVAN MEMARIAN, University of Cambridge 6 VICTOR B. F. GOMES, University of Cambridge 7 JENS GUSTEDT, INRIA 8 HUBERT TONG 9 10 11 This is a collection of examples exploring the semantics that should be allowed for objects 12 and subobjects in allocated regions – especially, where the defined/undefined-behaviour 13 boundary should be, and how that relates to compiler alias analysis. The examples are in 14 C, but much should be similar in C++. We refer to the ISO C notion of effective types, 15 but that turns out to be quite flawed. Some examples at the end (from Hubert Tong) show 16 that existing compiler behaviour is not consistent with type-changing updates. 17 This is an updated version of part of n2294 C Memory Object Model Study Group: 18 Progress Report, 2018-09-16. 19 1 INTRODUCTION 20 21 Paragraphs 6.5p{6,7} of the standard introduce effective types. These were added to 22 C in C99 to permit compilers to do optimisations driven by type-based alias analysis, 23 by ruling out programs involving unannotated aliasing of references to different types 24 (regarding them as having undefined behaviour). However, this is one of the less clear, 25 less well-understood, and more controversial aspects of the standard, as one can see from 1 2 26 various GCC and Linux Kernel mailing list threads , blog postings , and the responses to 3 4 27 Questions 10, 11, and 15 of our survey . See also earlier committee discussion . -
Memory Tagging and How It Improves C/C++ Memory Safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018
Memory Tagging and how it improves C/C++ memory safety Kostya Serebryany, Evgenii Stepanov, Aleksey Shlyapnikov, Vlad Tsyrklevich, Dmitry Vyukov Google February 2018 Introduction 2 Memory Safety in C/C++ 2 AddressSanitizer 2 Memory Tagging 3 SPARC ADI 4 AArch64 HWASAN 4 Compiler And Run-time Support 5 Overhead 5 RAM 5 CPU 6 Code Size 8 Usage Modes 8 Testing 9 Always-on Bug Detection In Production 9 Sampling In Production 10 Security Hardening 11 Strengths 11 Weaknesses 12 Legacy Code 12 Kernel 12 Uninitialized Memory 13 Possible Improvements 13 Precision Of Buffer Overflow Detection 13 Probability Of Bug Detection 14 Conclusion 14 Introduction Memory safety in C and C++ remains largely unresolved. A technique usually called “memory tagging” may dramatically improve the situation if implemented in hardware with reasonable overhead. This paper describes two existing implementations of memory tagging: one is the full hardware implementation in SPARC; the other is a partially hardware-assisted compiler-based tool for AArch64. We describe the basic idea, evaluate the two implementations, and explain how they improve memory safety. This paper is intended to initiate a wider discussion of memory tagging and to motivate the CPU and OS vendors to add support for it in the near future. Memory Safety in C/C++ C and C++ are well known for their performance and flexibility, but perhaps even more for their extreme memory unsafety. This year we are celebrating the 30th anniversary of the Morris Worm, one of the first known exploitations of a memory safety bug, and the problem is still not solved. -
Coredx DDS Type System
CoreDX DDS Type System Designing and Using Data Types with X-Types and IDL 4 2017-01-23 Table of Contents 1Introduction........................................................................................................................1 1.1Overview....................................................................................................................2 2Type Definition..................................................................................................................2 2.1Primitive Types..........................................................................................................3 2.2Collection Types.........................................................................................................4 2.2.1Enumeration Types.............................................................................................4 2.2.1.1C Language Mapping.................................................................................5 2.2.1.2C++ Language Mapping.............................................................................6 2.2.1.3C# Language Mapping...............................................................................6 2.2.1.4Java Language Mapping.............................................................................6 2.2.2BitMask Types....................................................................................................7 2.2.2.1C Language Mapping.................................................................................8 2.2.2.2C++ Language Mapping.............................................................................8 -
Statically Detecting Likely Buffer Overflow Vulnerabilities
Statically Detecting Likely Buffer Overflow Vulnerabilities David Larochelle [email protected] University of Virginia, Department of Computer Science David Evans [email protected] University of Virginia, Department of Computer Science Abstract Buffer overflow attacks may be today’s single most important security threat. This paper presents a new approach to mitigating buffer overflow vulnerabilities by detecting likely vulnerabilities through an analysis of the program source code. Our approach exploits information provided in semantic comments and uses lightweight and efficient static analyses. This paper describes an implementation of our approach that extends the LCLint annotation-assisted static checking tool. Our tool is as fast as a compiler and nearly as easy to use. We present experience using our approach to detect buffer overflow vulnerabilities in two security-sensitive programs. 1. Introduction ed a prototype tool that does this by extending LCLint [Evans96]. Our work differs from other work on static detection of buffer overflows in three key ways: (1) we Buffer overflow attacks are an important and persistent exploit semantic comments added to source code to security problem. Buffer overflows account for enable local checking of interprocedural properties; (2) approximately half of all security vulnerabilities we focus on lightweight static checking techniques that [CWPBW00, WFBA00]. Richard Pethia of CERT have good performance and scalability characteristics, identified buffer overflow attacks as the single most im- but sacrifice soundness and completeness; and (3) we portant security problem at a recent software introduce loop heuristics, a simple approach for engineering conference [Pethia00]; Brian Snow of the efficiently analyzing many loops found in typical NSA predicted that buffer overflow attacks would still programs. -
Julia's Efficient Algorithm for Subtyping Unions and Covariant
Julia’s Efficient Algorithm for Subtyping Unions and Covariant Tuples Benjamin Chung Northeastern University, Boston, MA, USA [email protected] Francesco Zappa Nardelli Inria of Paris, Paris, France [email protected] Jan Vitek Northeastern University, Boston, MA, USA Czech Technical University in Prague, Czech Republic [email protected] Abstract The Julia programming language supports multiple dispatch and provides a rich type annotation language to specify method applicability. When multiple methods are applicable for a given call, Julia relies on subtyping between method signatures to pick the correct method to invoke. Julia’s subtyping algorithm is surprisingly complex, and determining whether it is correct remains an open question. In this paper, we focus on one piece of this problem: the interaction between union types and covariant tuples. Previous work normalized unions inside tuples to disjunctive normal form. However, this strategy has two drawbacks: complex type signatures induce space explosion, and interference between normalization and other features of Julia’s type system. In this paper, we describe the algorithm that Julia uses to compute subtyping between tuples and unions – an algorithm that is immune to space explosion and plays well with other features of the language. We prove this algorithm correct and complete against a semantic-subtyping denotational model in Coq. 2012 ACM Subject Classification Theory of computation → Type theory Keywords and phrases Type systems, Subtyping, Union types Digital Object Identifier 10.4230/LIPIcs.ECOOP.2019.24 Category Pearl Supplement Material ECOOP 2019 Artifact Evaluation approved artifact available at https://dx.doi.org/10.4230/DARTS.5.2.8 Acknowledgements The authors thank Jiahao Chen for starting us down the path of understanding Julia, and Jeff Bezanson for coming up with Julia’s subtyping algorithm. -
Aliasing Restrictions of C11 Formalized in Coq
Aliasing restrictions of C11 formalized in Coq Robbert Krebbers Radboud University Nijmegen December 11, 2013 @ CPP, Melbourne, Australia int f(int *p, int *q) { int x = *p; *q = 314; return x; } If p and q alias, the original value n of *p is returned n p q Optimizing x away is unsound: 314 would be returned Alias analysis: to determine whether pointers can alias Aliasing Aliasing: multiple pointers referring to the same object Optimizing x away is unsound: 314 would be returned Alias analysis: to determine whether pointers can alias Aliasing Aliasing: multiple pointers referring to the same object int f(int *p, int *q) { int x = *p; *q = 314; return x; } If p and q alias, the original value n of *p is returned n p q Alias analysis: to determine whether pointers can alias Aliasing Aliasing: multiple pointers referring to the same object int f(int *p, int *q) { int x = *p; *q = 314; return x *p; } If p and q alias, the original value n of *p is returned n p q Optimizing x away is unsound: 314 would be returned Aliasing Aliasing: multiple pointers referring to the same object int f(int *p, int *q) { int x = *p; *q = 314; return x; } If p and q alias, the original value n of *p is returned n p q Optimizing x away is unsound: 314 would be returned Alias analysis: to determine whether pointers can alias It can still be called with aliased pointers: x union { int x; float y; } u; y u.x = 271; return h(&u.x, &u.y); &u.x &u.y C89 allows p and q to be aliased, and thus requires it to return 271 C99/C11 allows type-based alias analysis: I A compiler -
SATE V Ockham Sound Analysis Criteria
NISTIR 8113 SATE V Ockham Sound Analysis Criteria Paul E. Black Athos Ribeiro This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8113 NISTIR 8113 SATE V Ockham Sound Analysis Criteria Paul E. Black Software and Systems Division Information Technology Laboratory Athos Ribeiro Department of Computer Science University of Sao˜ Paulo Sao˜ Paulo, SP Brazil This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8113 March 2016 Including updates as of June 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Kent Rochford, Acting NIST Director and Under Secretary of Commerce for Standards and Technology Abstract Static analyzers examine the source or executable code of programs to find problems. Many static analyzers use heuristics or approximations to handle programs up to millions of lines of code. We established the Ockham Sound Analysis Criteria to recognize static analyzers whose findings are always correct. In brief the criteria are (1) the analyzer’s findings are claimed to always be correct, (2) it produces findings for most of a program, and (3) even one incorrect finding disqualifies an analyzer. This document begins by explaining the background and requirements of the Ockham Criteria. In Static Analysis Tool Exposition (SATE) V, only one tool was submitted to be re- viewed. Pascal Cuoq and Florent Kirchner ran the August 2013 development version of Frama-C on pertinent parts of the Juliet 1.2 test suite. We divided the warnings into eight classes, including improper buffer access, NULL pointer dereference, integer overflow, and use of uninitialized variable.