Exploring C Semantics and Pointer Provenance
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
CHERI C/C++ Programming Guide
UCAM-CL-TR-947 Technical Report ISSN 1476-2986 Number 947 Computer Laboratory CHERI C/C++ Programming Guide Robert N. M. Watson, Alexander Richardson, Brooks Davis, John Baldwin, David Chisnall, Jessica Clarke, Nathaniel Filardo, Simon W. Moore, Edward Napierala, Peter Sewell, Peter G. Neumann June 2020 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 https://www.cl.cam.ac.uk/ c 2020 Robert N. M. Watson, Alexander Richardson, Brooks Davis, John Baldwin, David Chisnall, Jessica Clarke, Nathaniel Filardo, Simon W. Moore, Edward Napierala, Peter Sewell, Peter G. Neumann, SRI International This work was supported by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and HR0011-18-C-0016 (“ECATS”). The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. This work was supported in part by the Innovate UK project Digital Security by Design (DSbD) Technology Platform Prototype, 105694. This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 789108), ERC Advanced Grant ELVER. We also acknowledge the EPSRC REMS Programme Grant (EP/K008528/1), Arm Limited, HP Enterprise, and Google, Inc. Approved for Public Release, Distribution Unlimited. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: https://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 3 Abstract This document is a brief introduction to the CHERI C/C++ programming languages. -
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 . -
Section “Common Predefined Macros” in the C Preprocessor
The C Preprocessor For gcc version 12.0.0 (pre-release) (GCC) Richard M. Stallman, Zachary Weinberg Copyright c 1987-2021 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.3 or any later version published by the Free Software Foundation. A copy of the license is included in the section entitled \GNU Free Documentation License". This manual contains no Invariant Sections. The Front-Cover Texts are (a) (see below), and the Back-Cover Texts are (b) (see below). (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 Table of Contents 1 Overview :::::::::::::::::::::::::::::::::::::::: 1 1.1 Character sets:::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Initial processing ::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3 Tokenization ::::::::::::::::::::::::::::::::::::::::::::::::::: 4 1.4 The preprocessing language :::::::::::::::::::::::::::::::::::: 6 2 Header Files::::::::::::::::::::::::::::::::::::: 7 2.1 Include Syntax ::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Include Operation :::::::::::::::::::::::::::::::::::::::::::::: 8 2.3 Search Path :::::::::::::::::::::::::::::::::::::::::::::::::::: 9 2.4 Once-Only Headers::::::::::::::::::::::::::::::::::::::::::::: 9 2.5 Alternatives to Wrapper #ifndef :::::::::::::::::::::::::::::: -
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. -
C2X Liaison: Removal of Deprecated Functions Title: Removal of Deprecated Functions Author: Nick Stoughton / the Austin Group Date: 2020-08-17
ISO/IEC JTC 1/SC 22/WG 14 Nxxxx Austin Group Document 1056 C2X Liaison: Removal of Deprecated Functions Title: Removal of Deprecated Functions Author: Nick Stoughton / The Austin Group Date: 2020-08-17 As stated in N2528, The Austin Group is currently in the process of revising the POSIX (ISO/IEC Std 9945), and is trying to keep aligned with C17 and C2X changes as necessary. There are several functions that are marked as "Obsolescent" in the current version of the POSIX standard that we would typically remove during this revision process. However, we note that in the current working draft for C2X the two obsolete functions "asctime_r()" and "ctime_r()" have been added. During the August 2020 WG 14 meeting, there was general agreement to seek a paper that more closely aligned the C2X functions with POSIX, noting that it was at very least odd that C2X should be adding functions already marked as obsolete. However, there was also concern that strftime, the proposed alternative to use for these new “asctime_r()” and “ctime_r()” , would “pull in locale baggage not wanted in small embedded programs”. Locale Free Alternatives It should be noted that asctime_r() is currently defined to be equivalent to a simple snprintf() call, and anyone who really wants a locale free way to print the date and time could use this. As an experiment, three equivalent simple programs were constructed: date1.c #include <stdio.h> #include <time.h> char * date1(const struct tm * timeptr , char * buf) { static const char wday_name[7][3] = { "Sun", "Mon", "Tue", "Wed", -
Half-Precision Floating-Point Formats for Pagerank: Opportunities and Challenges
Half-Precision Floating-Point Formats for PageRank: Opportunities and Challenges Molahosseini, A. S., & Vandierendonck, H. (2020). Half-Precision Floating-Point Formats for PageRank: Opportunities and Challenges. In 2020 IEEE High Performance Extreme Computing Conference, HPEC 2020 [9286179] (IEEE High Performance Extreme Computing Conference: Proceedings). Institute of Electrical and Electronics Engineers Inc.. https://doi.org/10.1109/HPEC43674.2020.9286179 Published in: 2020 IEEE High Performance Extreme Computing Conference, HPEC 2020 Document Version: Peer reviewed version Queen's University Belfast - Research Portal: Link to publication record in Queen's University Belfast Research Portal Publisher rights Copyright 2020 IEEE. This work is made available online in accordance with the publisher’s policies. Please refer to any applicable terms of use of the publisher. General rights Copyright for the publications made accessible via the Queen's University Belfast Research Portal is retained by the author(s) and / or other copyright owners and it is a condition of accessing these publications that users recognise and abide by the legal requirements associated with these rights. Take down policy The Research Portal is Queen's institutional repository that provides access to Queen's research output. Every effort has been made to ensure that content in the Research Portal does not infringe any person's rights, or applicable UK laws. If you discover content in the Research Portal that you believe breaches copyright or violates any law, please -
A Formal C Memory Model for Separation Logic
Journal of Automated Reasoning manuscript No. (will be inserted by the editor) A Formal C Memory Model for Separation Logic Robbert Krebbers Received: n/a Abstract The core of a formal semantics of an imperative programming language is a memory model that describes the behavior of operations on the memory. Defining a memory model that matches the description of C in the C11 standard is challenging because C allows both high-level (by means of typed expressions) and low-level (by means of bit manipulation) memory accesses. The C11 standard has restricted the interaction between these two levels to make more effective compiler optimizations possible, at the expense of making the memory model complicated. We describe a formal memory model of the (non-concurrent part of the) C11 stan- dard that incorporates these restrictions, and at the same time describes low-level memory operations. This formal memory model includes a rich permission model to make it usable in separation logic and supports reasoning about program transfor- mations. The memory model and essential properties of it have been fully formalized using the Coq proof assistant. Keywords ISO C11 Standard · C Verification · Memory Models · Separation Logic · Interactive Theorem Proving · Coq 1 Introduction A memory model is the core of a semantics of an imperative programming language. It models the memory states and describes the behavior of memory operations. The main operations described by a C memory model are: – Reading a value at a given address. – Storing a value at a given address. – Allocating a new object to hold a local variable or storage obtained via malloc. -
Remove Support for Function Definitions with Identifier Lists Lars Bjønnes, Jens Gustedt
Remove support for function definitions with identifier lists Lars Bjønnes, Jens Gustedt To cite this version: Lars Bjønnes, Jens Gustedt. Remove support for function definitions with identifier lists. [Research Report] N2432, ISO JCT1/SC22/WG14. 2019. hal-02311466 HAL Id: hal-02311466 https://hal.inria.fr/hal-02311466 Submitted on 10 Oct 2019 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. Distributed under a Creative Commons Attribution| 4.0 International License ISO/IEC JTC 1/SC 22/WG14 N2432 September 25, 2019 v 1 Remove support for function definitions with identifier lists proposal for C2x Lars Gullik Bjønnes and Jens Gustedt CISCO Inc., Norway and INRIA and ICube, Universit´ede Strasbourg, France Function definitions with identifier lists (often referred to as K&R functions) are deprecated for a long time. Because they are now clearly phased out everywhere and because function declarations and definitions that provide a prototypes are clearly superior we propose to remove this feature for good. 1. INTRODUCTION The original syntax for definitions with identifier lists and a subsequent declarator list has the disadvantage that it does not provide a prototype of the defined function, and that the function needs a special convention (called default argument promotion) that leaves the verification of type correspondance between caller and callee to the programmer. -
Abkürzungs-Liste ABKLEX
Abkürzungs-Liste ABKLEX (Informatik, Telekommunikation) W. Alex 1. Juli 2021 Karlsruhe Copyright W. Alex, Karlsruhe, 1994 – 2018. Die Liste darf unentgeltlich benutzt und weitergegeben werden. The list may be used or copied free of any charge. Original Point of Distribution: http://www.abklex.de/abklex/ An authorized Czechian version is published on: http://www.sochorek.cz/archiv/slovniky/abklex.htm Author’s Email address: [email protected] 2 Kapitel 1 Abkürzungen Gehen wir von 30 Zeichen aus, aus denen Abkürzungen gebildet werden, und nehmen wir eine größte Länge von 5 Zeichen an, so lassen sich 25.137.930 verschiedene Abkür- zungen bilden (Kombinationen mit Wiederholung und Berücksichtigung der Reihenfol- ge). Es folgt eine Auswahl von rund 16000 Abkürzungen aus den Bereichen Informatik und Telekommunikation. Die Abkürzungen werden hier durchgehend groß geschrieben, Akzente, Bindestriche und dergleichen wurden weggelassen. Einige Abkürzungen sind geschützte Namen; diese sind nicht gekennzeichnet. Die Liste beschreibt nur den Ge- brauch, sie legt nicht eine Definition fest. 100GE 100 GBit/s Ethernet 16CIF 16 times Common Intermediate Format (Picture Format) 16QAM 16-state Quadrature Amplitude Modulation 1GFC 1 Gigabaud Fiber Channel (2, 4, 8, 10, 20GFC) 1GL 1st Generation Language (Maschinencode) 1TBS One True Brace Style (C) 1TR6 (ISDN-Protokoll D-Kanal, national) 247 24/7: 24 hours per day, 7 days per week 2D 2-dimensional 2FA Zwei-Faktor-Authentifizierung 2GL 2nd Generation Language (Assembler) 2L8 Too Late (Slang) 2MS Strukturierte -
Low−Level C Topic for CS2263 Alumni −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− People Who Have Taken CS2617 Should Instead Read the Full Set of Notes (Cnotes)
Low−level C Topic for CS2263 Alumni −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− People who have taken CS2617 should instead read the full set of notes (cnotes). Note: 2nd ed of textbook was for C−89 (classic "ANSI−C". Third is based on the 2018 revision. There were many changes in 30 years. C−11 and C−99 are also in widespread use. A new version (currently called C−2X) is expected in 2021 or 2022. Change look fairly small (new "decimal floats", if you care.) The Preprocessor −−−−−−−−−−−−−−−− Unlike Java, the C compiler has a "preprocessor" that does textual substitutions and "conditional compilation" before the "real compiler" runs. This was borrowed from assembly languages. Fancy uses of preprocessor are often deprecated, especially since C99. Still commonly used use for defining constants and in doing the C equivalent to Java’s "import". Preprocessor "directives" start with #. No ’;’ at end Macros in the C Preprocessor −−−−−−−−−−−−−−−−−−−−−−−−−−−−− #define FOO 12*2 thereafter, wherever the symbol FOO occurs in your code, it is textually replaced by 12*2 . Think find−and−replace. Macro can have parameters #define BAR(x) 12*x If we have BAR(3*z) in your code, it is textually replaced by 12*3*z #undef BAR will "undefine" BAR. After this, BAR(3*z) remains as is. Perils of Macros −−−−−−−−−−−−−−−−− #define SQUARE(x) ((x)*(x)) used much later with int x = 0; int y = SQUARE(x++); What value for x is expected by a programmer looking only at these lines? What value does x actually have? Making Strings and Concatenating Tokens −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− (optional fancy topic) In a macro definition, the # operator puts quote marks around a macro argument.