DOCSLIB.ORG

3.13.0 16/Apr/21 OP-TEE 3.12.0 20/Jan/21 OP-TEE 3.11.0 16/Oct/20 OP-TEE 3.10.0 21/Aug/20

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
3.13.0 16/Apr/21 OP-TEE 3.12.0 20/Jan/21 OP-TEE 3.11.0 16/Oct/20 OP-TEE 3.10.0 21/Aug/20 OP-TEE Documentation TrustedFirmware.org Apr 30, 2021 Contents 1 Getting started 3 1.1 About OP-TEE..............................................3 1.2 Coding standards.............................................4 1.3 Contribute................................................5 1.4 Contact..................................................8 1.5 License headers.............................................9 1.6 Platforms supported........................................... 10 1.7 Presentations............................................... 11 1.8 Releases................................................. 13 2 Architecture 17 2.1 Core................................................... 17 2.2 Cryptographic implementation...................................... 37 2.3 Device Tree................................................ 40 2.4 File structure............................................... 41 2.5 GlobalPlatform API........................................... 43 2.6 Libraries................................................. 53 2.7 Porting guidelines............................................ 53 2.8 Secure boot................................................ 59 2.9 Secure storage.............................................. 60 2.10 Trusted Applications........................................... 67 2.11 Virtualization............................................... 77 3 Build and run 81 3.1 Prerequisites............................................... 81 3.2 Device specific information....................................... 82 3.3 AOSP................................................... 103 3.4 Linux kernel TEE framework...................................... 106 3.5 OP-TEE gits............................................... 106 3.6 Toolchains................................................ 136 3.7 Trusted Applications........................................... 137 3.8 StandAloneMM............................................. 144 4 Debugging techniques 147 4.1 Abort dumps / call stack......................................... 147 4.2 Benchmark framework.......................................... 149 4.3 Ftrace................................................... 152 i 4.4 Gprof................................................... 153 5 Frequently Asked Questions 155 5.1 Abbreviations............................................... 157 5.2 Architecture............................................... 157 5.3 Board support.............................................. 159 5.4 Building................................................. 159 5.5 Certification and security reviews.................................... 160 5.6 Contribution............................................... 161 5.7 Interfaces................................................. 162 5.8 Hardware and peripherals........................................ 163 5.9 License.................................................. 163 5.10 Promotion................................................ 163 5.11 Security vulnerabilities.......................................... 164 5.12 Source code............................................... 164 5.13 Testing.................................................. 164 5.14 Trusted Applications........................................... 165 ii OP-TEE Documentation This is the official location for OP-TEE documentation. Contents 1 OP-TEE Documentation 2 Contents CHAPTER 1 Getting started This contains general information about OP-TEE, how to get in contact, how to contribute, how to report security issues etc. It is intended for people who are new to OP-TEE. 1.1 About OP-TEE OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. OP-TEE implements TEE Internal Core API v1.1.x which is the API exposed to Trusted Applications and the TEE Client API v1.0, which is the API describing how to communicate with a TEE. Those APIs are defined in the GlobalPlatform API specifications. The non-secure OS is referred to as the Rich Execution Environment (REE) in TEE specifications. It is typically a Linux OS flavor as a GNU/Linux distribution or the AOSP. OP-TEE is designed primarily to rely on the Arm TrustZone technology as the underlying hardware isolation mech- anism. However, it has been structured to be compatible with any isolation technology suitable for the TEE concept and goals, such as running as a virtual machine or on a dedicated CPU. The main design goals for OP-TEE are: • Isolation - the TEE provides isolation from the non-secure OS and protects the loaded Trusted Applications (TAs) from each other using underlying hardware support, • Small footprint - the TEE should remain small enough to reside in a reasonable amount of on-chip memory as found on Arm based systems, • Portability - the TEE aims at being easily pluggable to different architectures and available HW and has to support various setups such as multiple client OSes or multiple TEEs. 1.1.1 OP-TEE components OP-TEE is divided in various components: • A secure privileged layer, executing at Arm secure PL-1 (v7-A) or EL-1 (v8-A) level. 3 OP-TEE Documentation • A set of secure user space libraries designed for Trusted Applications needs. • A Linux kernel TEE framework and driver (merged to the official tree in v4.12). • A Linux user space library designed upon the GlobalPlatform TEE Client API specifications. • A Linux user space supplicant daemon (tee-supplicant) responsible for remote services expected by the TEE OS. • A test suite (xtest), for doing regression testing and testing the consistency of the API implementations. • An example git containing a couple of simple host- and TA-examples. • And some build scripts, debugging tools to ease its integration and the development of Trusted Applications and secure services. These components are available from several git repositories. The main ones are build, optee_os, optee_client, optee_test, optee_examples and the Linux kernel TEE framework. 1.1.2 History OP-TEE was initially developed by ST-Ericsson (and later on by STMicroelectronics), but this was before OP-TEE got the name “OP-TEE” and was turned into an open source project. Back then it was a closed source and a proprietary TEE project. In 2013, ST-Ericsson obtained GlobalPlatform’s compliance qualification with this implementation, proving that the APIs were behaving as expected according to the GlobalPlatform specifications. Later on the same year (2013) Linaro was about to form Security Working Group (SWG) and one of the initial key tasks for SWG was to work on an open source TEE project. After talking to various TEE vendors Linaro ended up working with STMicroelectronics TEE project. But before being able to open source it there was a need to replace some proprietary components with open source components. For a couple of months Linaro/SWG together with engineers from STMicroelectronics re-wrote major parts (crypto library, secure monitor, build system etc), cleaned up the project by enforcing Coding standards, running checkpatch etc. June 12 2014 was the day when OP-TEE was “born” as an open source project. At that day the OP-TEE team pushed the first commit to GitHub. A bit after this Linaro also made a press release about this. That press release contains a bit more information. At the first year as an open source project it was owned by STMicroelectronics but maintained by Linaro and STMicroelectronics. In 2015 there was an ownership transfer of OP-TEE from STMicroelectronics to Linaro. In September 2019, ownership was transferred from Linaro to the TrustedFirmware.org project (see _blogpost for more information). Maintenance is a shared responsibility between the members for TrustedFirmware.org and some community maintainers representing other companies who are using OP-TEE. 1.2 Coding standards In this project we are trying to adhere to the same coding convention as used in the Linux kernel (see CodingStyle). We achieve this by running checkpatch from Linux kernel. However there are a few exceptions that we had to make since the code also follows GlobalPlatform standards. The exceptions are as follows: 1. CamelCase for GlobalPlatform types is allowed. 2. We do not run checkpatch on third party code that we might use in this project, such as LibTomCrypt, MPA, newlib etc. The reason for that and not doing checkpatch fixes for third party code is because we would probably deviate too much from upstream and therefore it would be hard to rebase against those projects later on and we don’t expect that it is easy to convince other software projects to change coding style. 3. All variables shall be initialized to a well known value in one or another way. The reason for that is that we have had potential security issues in the past that originated from not having variables initialized with a well defined value. We have also investigate various toolchain flags that are supposed to help out finding uninitialized 4 Chapter 1. Getting started OP-TEE Documentation variables. Unfortunately our conclusion is that you cannot trust the compilers here, since there are corner cases where compilers cannot reliably give a warning. Variables are initialized according to these general guidelines: • Scalars (and types like time_t which are standardized as scalars) are initialized with 0, unless another value makes more sense. • For optee_client we need maximum portability. So use { 0 } for struct types where the first element is known to be a scalar and memset() otherwise unless there is a good reason not to do so. •
Load more

Recommended publications
  • Truffle/C Interpreter
    JOHANNES KEPLER UNIVERSITAT¨ LINZ JKU Faculty of Engineering and Natural Sciences Truffle/C Interpreter Master’s Thesis submitted in partial fulfillment of the requirements for the academic degree Diplom-Ingenieur in the Master’s Program Computer Science Submitted by Manuel Rigger, BSc. At the Institut f¨urSystemsoftware Advisor o.Univ.-Prof. Dipl.-Ing. Dr.Dr.h.c. Hanspeter M¨ossenb¨ock Co-advisor Dipl.-Ing. Lukas Stadler Dipl.-Ing. Dr. Thomas W¨urthinger Xiamen, April 2014 Contents I Contents 1 Introduction 3 1.1 Motivation . .3 1.2 Goals and Scope . .4 1.3 From C to Java . .4 1.4 Structure of the Thesis . .6 2 State of the Art 9 2.1 Graal . .9 2.2 Truffle . 10 2.2.1 Rewriting and Specialization . 10 2.2.2 Truffle DSL . 11 2.2.3 Control Flow . 12 2.2.4 Profiling and Inlining . 12 2.2.5 Partial Evaluation and Compilation . 12 2.3 Clang . 13 3 Architecture 14 3.1 From Clang to Java . 15 3.2 Node Construction . 16 3.3 Runtime . 16 4 The Truffle/C File 17 4.1 Truffle/C File Format Goals . 17 4.2 Truffle/C File Format 1 . 19 4.2.1 Constant Pool . 19 4.2.2 Function Table . 20 4.2.3 Functions and Attributes . 20 4.3 Truffle/C File Considerations and Comparison . 21 4.3.1 Java Class File and Truffle/C File . 21 4.3.2 ELF and Truffle/C File . 22 4.4 Clang Modification Truffle/C File . 23 Contents II 5 Truffle/C Data Types 25 5.1 Data Type Hierarchy: Boxing, Upcasts and Downcasts .
    [Show full text]
  • Contents of Lecture 4: Declarations
    Contents of Lecture 4: Declarations Implicint int Storage class specifiers Type specifiers Enumeration specifiers Type qualifiers Jonas Skeppstedt ([email protected]) Lecture 4 2014 1 / 39 Now obsolete: implicit int Sometimes you can see code such as: main() // invalid { } or even: #include <stdio.h> count; // invalid float x; In earlier versions of C one could skip the type, which then became int, and is called implicit int. Calling a function before its declaration also set its return type to int. It’s invalid C so don’t use it — but compilers often allow it... Jonas Skeppstedt ([email protected]) Lecture 4 2014 2 / 39 Storage class specifiers Last lecture we discussed the different kinds of storage durations. Now we will see how to specify some of them explicitly. Dynamic (important) and temporary (less important) storage duration are not specified by the programmer using any particular syntax but defined by the standard. The storage class specifiers are: typedef extern static _Thread_local auto register Of these typedef does not refer to any kind of storage duration — instead it introduces another name of a type and not a new type: typedef int num_t; int* p; num_t* q; p = q; // valid since p and q have the same type. Jonas Skeppstedt ([email protected]) Lecture 4 2014 3 / 39 Storage class specifiers: static at file scope static int count; /∗ initialized to zero. ∗/ static void init(void) { /∗ Do some initializations ... ∗/ } Used to make an identifier invisible outside the source file With static at file scope, there is no risk of name conflicts with other files.
    [Show full text]
  • ACCU 2015 “New” Features in C
    "New" Features in C ACCU 2015 “New” Features in C Dan Saks Saks & Associates www.dansaks.com 1 Abstract The first international standard for the C programming language was C90. Since then, two newer standards have been published, C99 and C11. C99 introduced a significant number of new features. C11 introduced a few more, some of which have been available in compilers for some time. Curiously, many of these added features don’t seem to have caught on. Many C programmers still program in C90. This session explains many of these “new” features, including declarations in for-statements, typedef redefinitions, inline functions, complex arithmetic, extended integer types, variable- length arrays, flexible array members, compound literals, designated initializers, restricted pointers, type-qualified array parameters, anonymous structures and unions, alignment support, non-returning functions, and static assertions. 2 Copyright © 2015 by Daniel Saks 1 "New" Features in C About Dan Saks Dan Saks is the president of Saks & Associates, which offers training and consulting in C and C++ and their use in developing embedded systems. Dan has written columns for numerous print publications including The C/C++ Users Journal , The C++ Report , Software Development , and Embedded Systems Design . He currently writes the online “Programming Pointers” column for embedded.com . With Thomas Plum, he wrote C++ Programming Guidelines , which won a 1992 Computer Language Magazine Productivity Award . He has also been a Microsoft MVP. Dan has taught thousands of programmers around the world. He has presented at conferences such as Software Development and Embedded Systems , and served on the advisory boards for those conferences.
    [Show full text]
  • XL C/C++: Language Reference About This Document
    IBM XL C/C++ for Linux, V16.1.1 IBM Language Reference Version 16.1.1 SC27-8045-01 IBM XL C/C++ for Linux, V16.1.1 IBM Language Reference Version 16.1.1 SC27-8045-01 Note Before using this information and the product it supports, read the information in “Notices” on page 63. First edition This edition applies to IBM XL C/C++ for Linux, V16.1.1 (Program 5765-J13, 5725-C73) and to all subsequent releases and modifications until otherwise indicated in new editions. Make sure you are using the correct edition for the level of the product. © Copyright IBM Corporation 1998, 2018. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents About this document ......... v Chapter 4. IBM extension features ... 11 Who should read this document........ v IBM extension features for both C and C++.... 11 How to use this document.......... v General IBM extensions ......... 11 How this document is organized ....... v Extensions for GNU C compatibility ..... 15 Conventions .............. v Extensions for vector processing support ... 47 Related information ........... viii IBM extension features for C only ....... 56 Available help information ........ ix Extensions for GNU C compatibility ..... 56 Standards and specifications ........ x Extensions for vector processing support ... 58 Technical support ............ xi IBM extension features for C++ only ...... 59 How to send your comments ........ xi Extensions for C99 compatibility ...... 59 Extensions for C11 compatibility ...... 59 Chapter 1. Standards and specifications 1 Extensions for GNU C++ compatibility .... 60 Chapter 2. Language levels and Notices .............. 63 language extensions ......... 3 Trademarks .............
    [Show full text]
  • Qa·C Release Notes
    RELEASE NOTES QA·C 9.4.1 February, 2018 Documentation Version 1.3 IMPORTANT NOTICE DISCLAIMER OF WARRANTY This document should only be used in conjunction with QA·C 9.4.1. Programming Research Ltd. have taken due care in preparing this document which it has endeavored to ensure is accurate at the time of printing. However, no liability can be accepted for errors or omissions; nor should the document be considered as an expressed or implied warranty of accuracy or completeness, fitness for a particular purpose, or that the products described perform as specified within. COPYRIGHT NOTICE All rights reserved. No part of this document may be reproduced, stored in a retrieval system of any nature, or transmitted in any form or by any means, including photocopying and recording, without the prior written permission of Programming Research Ltd., the copyright owner. If any unauthorized acts are carried out in relation to this copyrighted work, a civil claim for damages may be made and/or a criminal prosecution may result. Copyright ©Programming Research Ltd. 2018 TRADEMARKS PRQA, the PRQA logo, QA·C, QA·C++ and High Integrity C++ (HIC++) are trademarks of Programming Research Ltd. "MISRA", "MISRA C" and "MISRA C++" are registered trademarks of HORIBA MIRA Lim- ited, held on behalf of the MISRA Consortium. "AUTOSAR" is a registered trademark of AUTOSAR GBR, held on behalf of the AU- TOSAR Development Partnership. Yices is a registered trademark of SRI International. Windows is a registered trademark of Microsoft Corporation. RELEASE NOTES : QA·C 9.4.1 Page i Programming Research Ltd.
    [Show full text]
  • C-STAT® Static Analysis Guide
    C-STAT® Static Analysis Guide CSTAT-14 COPYRIGHT NOTICE © 2015–2021 IAR Systems AB and Synopsys, Inc. No part of this document may be reproduced without the prior written consent of IAR Systems AB. The software described in this document is furnished under a license and may only be used or copied in accordance with the terms of such a license. This publication incorporates portions of the Technical Report, “SEI CERT C Coding Standard Rules for Developing Safe, Reliable, and Secure Systems 2016 Edition,” by CERT. © 2016 Carnegie Mellon University, with special permission from its Software Engineering Institute. DISCLAIMERS The information in this document is subject to change without notice and does not represent a commitment on any part of IAR Systems. While the information contained herein is assumed to be accurate, IAR Systems assumes no responsibility for any errors or omissions. In no event shall IAR Systems, its employees, its contractors, or the authors of this document be liable for special, direct, indirect, or consequential damage, losses, costs, charges, claims, demands, claim for lost profits, fees, or expenses of any nature or kind. Any material of Carnegie Mellon University and/or its software engineering institute contained herein is furnished on an “as-is” basis. Carnegie Mellon University makes no warranties of any kind, either expressed or implied, as to any matter including, but not limited to, warranty of fitness for purpose or merchantability, exclusivity, or results obtained from use of the material. Carnegie Mellon University does not make any warranty of any kind with respect to freedom from patent, trademark, or copyright infringement.
    [Show full text]
  • Vbcc Compiler System
    vbcc compiler system Volker Barthelmann i Table of Contents 1 General :::::::::::::::::::::::::::::::::::::::::: 1 1.1 Introduction ::::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.2 Legal :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 1.3 Installation :::::::::::::::::::::::::::::::::::::::::::::::::::: 2 1.3.1 Installing for Unix::::::::::::::::::::::::::::::::::::::::: 3 1.3.2 Installing for DOS/Windows::::::::::::::::::::::::::::::: 3 1.3.3 Installing for AmigaOS :::::::::::::::::::::::::::::::::::: 3 1.4 Tutorial :::::::::::::::::::::::::::::::::::::::::::::::::::::::: 5 2 The Frontend ::::::::::::::::::::::::::::::::::: 7 2.1 Usage :::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 7 2.2 Configuration :::::::::::::::::::::::::::::::::::::::::::::::::: 8 3 The Compiler :::::::::::::::::::::::::::::::::: 11 3.1 General Compiler Options::::::::::::::::::::::::::::::::::::: 11 3.2 Errors and Warnings :::::::::::::::::::::::::::::::::::::::::: 15 3.3 Data Types ::::::::::::::::::::::::::::::::::::::::::::::::::: 15 3.4 Optimizations::::::::::::::::::::::::::::::::::::::::::::::::: 16 3.4.1 Register Allocation ::::::::::::::::::::::::::::::::::::::: 18 3.4.2 Flow Optimizations :::::::::::::::::::::::::::::::::::::: 18 3.4.3 Common Subexpression Elimination :::::::::::::::::::::: 19 3.4.4 Copy Propagation :::::::::::::::::::::::::::::::::::::::: 20 3.4.5 Constant Propagation :::::::::::::::::::::::::::::::::::: 20 3.4.6 Dead Code Elimination::::::::::::::::::::::::::::::::::: 21 3.4.7 Loop-Invariant Code Motion
    [Show full text]
  • Coverity Support for SEI CERT C, C++, and Java Coding Standards
    Coverity Support for SEI CERT C, C++, and Java Coding Standards Ensure the safety, The SEI CERT C, C++, and Oracle Java Coding Standards are lists of rules and reliability, and security recommendations for writing secure code in the C, C++, and Java programming languages They represent an important milestone in introducing best practices for of software written in C, ensuring the safety, reliability, security, and integrity of software written in C/C++ and C++, and Java Java Notably, the standards are designed to be enforceable by software code analyzers using static analysis techniques This greatly reduces the cost of compliance by way of automation Adhering to coding standards is a crucial step in establishing best coding practices Standards adherence is particularly important in safety-critical, high-impact industries, such as automotive, medical, and networking Software defects in products coming from these industries manifest themselves physically and tangibly—often with life- threatening consequences Synopsys provides a comprehensive solution for the SEI CERT C/C++ Coding Standards rules, along with high-impact SEI CERT Oracle Java Coding Standards (online version) rules and SEI CERT C Coding Standard recommendations (online version) Coverity static analysis implements the Rules category within the CERT C/ C++ standards, high-impact CERT Java L1 rules, and methods for managing violations and reporting on them Coverity also supports some of the best practices from the Recommendations category for the CERT C standard Acknowledgement
    [Show full text]
  • In Using the GNU Compiler Collection (GCC)
    Using the GNU Compiler Collection For gcc version 6.1.0 (GCC) Richard M. Stallman and the GCC Developer Community Published by: GNU Press Website: http://www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 51 Franklin Street, Fifth Floor Tel 617-542-5942 Boston, MA 02110-1301 USA Fax 617-542-2652 Last printed October 2003 for GCC 3.3.1. Printed copies are available for $45 each. Copyright c 1988-2016 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; with the Invariant Sections being \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 ::::::::::::::::::::::::::::::: 9 4 C Implementation-Defined Behavior :::::::::::::::::::: 373 5 C++ Implementation-Defined Behavior ::::::::::::::::: 381 6 Extensions to
    [Show full text]
  • TR0109 TSK3000 Embedded Tools Reference
    TSK3000 Embedded Tools Reference TR0109 Nov 22, 2010 Software, hardware, documentation and related materials: Copyright E 2010 Altium Limited. All Rights Reserved. The material provided with this notice is subject to various forms of national and international intellectual property protection, including but not limited to copyright protection. You have been granted a non-exclusive license to use such material for the purposes stated in the end-user license agreement governing its use. In no event shall you reverse engineer, decompile, duplicate, distribute, create derivative works from or in any way exploit the material licensed to you except as expressly permitted by the governing agreement. Failure to abide by such restrictions may result in severe civil and criminal penalties, including but not limited to fines and imprisonment. Provided, however, that you are permitted to make one archival copy of said materials for back up purposes only, which archival copy may be accessed and used only in the event that the original copy of the materials is inoperable. Altium, Altium Designer, Board Insight, DXP, Innovation Station, LiveDesign, NanoBoard, NanoTalk, OpenBus, P-CAD, SimCode, Situs, TASKING, and Topological Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. v8.0 31/3/08 Table of Contents Table of Contents C Language 1-1 1.1 Introduction . .. .. .. .. .. .. 1-1 1.2 Data Types . .. .. .. .. .. .. 1-2 1.2.1 Changing the Alignment: __unaligned, __packed__ and __align().
    [Show full text]
  • Using the GNU Compiler Collection
    Using the GNU Compiler Collection For gcc version 4.2.4 Richard M. Stallman and the GCC Developer Community Published by: GNU Press Website: www.gnupress.org a division of the General: [email protected] Free Software Foundation Orders: [email protected] 51 Franklin Street, Fifth Floor Tel 617-542-5942 Boston, MA 02110-1301 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, 2005 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 ............................... 7 4 C Implementation-defined behavior ..................... 215 5 Extensions to the C Language Family ................... 223 6 Extensions to the C++ Language .....................
    [Show full text]
  • 15-122: Principles of Imperative Computation Recitation 23 The
    15-122: Principles of Imperative Computation Recitation 23 Section C November 16, 2012 The switch/case construct Given int expression e, constants c1, c2, ..., cn, the following are roughly equivalent: switch (e) { int x = e; case c1: if (x == c1) <statement 1> <statement 1> break; else if (x == c2) <statement 2> case c2: ... <statement 2> else if (x == cn) break; <statement n> else ... <default statement> case cn: <statement n> break; default: <default statement> break; } Note: the 'break;' statements in the cases of the switch are important: without a 'break;', control falls through to the following case. This design choice can easily lead to unexpected behaviors. Consider: switch (x % 2) { case 0: printf("x is even\n"); case 1: printf("x" is odd\n"); } You can make hella elegant code sometimes by exploiting the fallthrough behavior of cases: switch(x) { case 1: case 4: case 9: { int sx = isqrt(x); printf("sqrt(x) = %d\n", sx); break; } default: printf("not a perfect square...\n"); } The entire main loop of your VM will be one big switch statement. Be wary of fallthrough! 1 Structs that aren't pointers In C0 and in much of our C programming, we have accessed structs through pointers almost exclusively. typedef struct stack * stack; struct stack { list top; }; ... stack S = stack_new(); ... ... S->top ... Sometimes it's convenient to access structs directly, though, like when they're stored in an array. To access a field f of a struct expression e, one uses the syntax 'e.f'. stack stack_array[] = ... ... stack_array[i].top ... In fact, the familiar notation 'p->f' for accessing a struct field through a pointer p is just syntactic sugar for '(*p).f', and since array indexing is just syntactic sugar for pointer arithmetic, the above expression really amounts to '(*(stack_array+i)).top', or (stack_array+i)->top.
    [Show full text]