Types and Systems Programming Advanced Systems Programming (M) Lecture 2 Colin Perkins | https://csperkins.org/ | Copyright © 2019 | This work is licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Lecture Outline • Strongly Typed Languages • What is a strongly typed language? • Why is strong typing desirable? • Types for systems programming • Introducing the Rust programming language • Basic operations and types • Arrays, vectors, tuples, strings • Structures and traits • Enumerated types and pattern matching • Memory allocation and boxes • Why is Rust interesting? Colin Perkins | https://csperkins.org/ | Copyright © 2019 !2 • What is a strongly typed language? Strongly Typed Languages • Why is strong typing desirable? • Types for systems programming Colin Perkins | https://csperkins.org/ | Copyright © 2019 !3 What is a Type? • A type describes what an item of data represents • Is it an integer? floating point value? file? sequence number? username? • What, conceptually, is the data? • How is it represented? • Types are very familiar in programming: int x; Declaring variables and specifying their type double y; char *hello = “Hello, world”; struct sockaddr_in { Declaring a new type uint8_t sin_len; sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; char sin_pad[16]; }; Colin Perkins | https://csperkins.org/ | Copyright © 2019 !4 What is a Type System? • A type system is a set of rules constraining how types can be used: • What operations can be performed on a type? • What operations can be performed with a type? • How does a type compose with other types of data? • A type system proves the absence of certain program behaviours • It doesn’t guarantee the program is correct • It does guarantee that some incorrect behaviours do not occur • A good type system eliminates common classes of bug, without adding too much complexity • A bad type system adds complexity to the language, but doesn't prevent many bugs • Type-related checks can happen at compile time, at run time, or both • e.g., array bounds checks are a property of an array type, checked at run time Colin Perkins | https://csperkins.org/ | Copyright © 2019 !5 Static and Dynamic Types (1/2) • In a language with static types, the type of a variable is fixed when the variable is created: • Some require types to be explicitly declared; others can infer types from context • C and Java requires the types to be explicitly stated in all cases • Haskell, Rust, OCaml, ... can infer from the context • Just because the language can infer the type does not mean the type is dynamic: > cat src/main.rs fn main() { let x = 6; x += 4.2; println!("{}", x); } > cargo build Compiling hello v0.1.0 (/Users/csp/tmp/hello) error[E0277]: cannot add-assign `{float}` to `{integer}` --> src/main.rs:3:7 | 3 | x += 4.2; | ^^ no implementation for `{integer} += {float}` | = help: the trait `std::ops::AddAssign<{float}>` is not implemented for `{integer}` error: aborting due to previous error • The Rust compiler infers that x is an integer and won’t let us add a floating point 4.2 to it, since that would require changing its type Colin Perkins | https://csperkins.org/ | Copyright © 2019 !6 Static and Dynamic Types (2/2) • In a language with dynamic types, the type of a variable can change during its lifetime > python3 Python 3.6.2 (v3.6.2:5fd33b5926, Jul 16 2017, 20:11:06) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> x = 6 >>> type(x) <class 'int'> >>> x += 4.2 >>> type(x) <class 'float'> >>> • Dynamically typed languages tend to be lower performance, but offer more flexibility • They have to store the type as well as its value, which takes additional memory • They can make fewer optimisation based on the type of a variable, since that type can change • Systems languages generally have static types, and be compiled ahead of time, since they tend to be performance sensitive Colin Perkins | https://csperkins.org/ | Copyright © 2019 !7 Strong and Weak Types (1/2) • In a language with strong types, every operation must conform to the type system • If the compiler and/or run-time cannot prove that the operation is legal according to the type rules, the operation is not permitted • Other languages have weaker types, and provide ways of circumventing the type checker: • This might be automatic safe conversions between types: float x = 6.0; C has static types, but allows lower precision values to be assigned double y = 5.0; to variables with higher precision types – there’s no data loss double z = x + y; • Or it might be an open-ended cast: char *buffer[BUFLEN]; Common C programming idiom: casting between int fd = socket(…); types using pointers to evade the type system … if (recv(fd, buffer, BUFLEN, 0) > 0) { struct rtp_packet *p = (struct rtp_packet *) buf; … } Colin Perkins | https://csperkins.org/ | Copyright © 2019 !8 Strong and Weak Types (2/2) • Sometimes clearer to consider safe and unsafe languages, rather than strong or weak types • “A safe language is one that protects its own abstractions” [Pierce] • A safe language – whether static or dynamic – knows the types of all variables, and only allows legal operations on those values • An unsafe language allows the types to be circumvented – to perform operations that the programmer believes are correct, but the type system can’t prove so Colin Perkins | https://csperkins.org/ | Copyright © 2019 !9 Why is Strong Typing Desirable? • “Well-typed programs don’t go wrong” – Robin Milner • The result is well-defined – although not necessarily correct • The type system ensures results are consistent with the rules of the language, but cannot check if you calculated the right result • A strongly-typed system will only ever perform operations on a type that are legal – there is no undefined behaviour • Types help model the problem, check for consistency, and eliminate common classes of bug Colin Perkins | https://csperkins.org/ | Copyright © 2019 !10 Segmentation fault (core dumped) Segmentation faults should never happen: • Compiler and runtime should strongly enforce type rules • If program violates them, it should be terminated cleanly • Security vulnerabilities – e.g., buffer overflow attacks – come from undefined behaviour after type violations Colin Perkins | https://csperkins.org/ | Copyright © 2019 !11 1 The behavior is undefined in the following circumstances: — A ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated (clause 4). — A nonempty source file does not end in a new-line character which is not immediately preceded by a backslash character or ends in a partial preprocessing token or comment (5.1.1.2). — Token concatenation produces a character sequence matching the syntax of a universal character name (5.1.1.2). — A program in a hosted environment does not define a function named main using one Segmentation fault (core dumped)of the specified forms (5.1.2.2.1). —§J.2 The execution of a program containsPortability a data race issues (5.1.2.4). 557 — A character not in the basic source character set is encountered in a source file, except ISO/IEC 9899:201x Committee Draft — April 12, 2011 N1570 in an identifier, a character constant, a string literal, a header name, a comment, or a preprocessing token that is never converted to a token (5.2.1). — An identifier, comment, string literal, character constant, or header name contains an 2 EXAMPLE An example of locale-specific behavior is whether the islower function returns true for characters other than the 26 lowercase Latin letters. invalid multibyte character or does not begin and end in the initial shift state (5.2.1.2). 3.4.3 — The same identifier has both internal and external linkage in the same translation unit 1 undefined behavior (6.2.2). behavior, upon use of a nonportable or erroneous program construct or of erroneous data, — An object is referred to outside of its lifetime (6.2.4). for which this International Standard imposes no requirements — The value of a pointer to an object whose lifetime has ended is used (6.2.4). 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the — The value of an object with automatic storage duration is used while it is environment (with or without the issuance of a diagnostic message), to terminating a translation or indeterminate (6.2.4, 6.7.9, 6.8). execution (with the issuance of a diagnostic message). 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow. — A trap representation is read by an lvalue expression that does not have character type (6.2.6.1). 3.4.4 1 unspecified behavior — A trap representation is produced by a side effect that modifies any part of the object use of an unspecified value, or other behavior where this International Standard provides using an lvalue expression that does not have character type (6.2.6.1). C hastwo or 193 more possibilities kinds and imposes of undefinedno further requirements onbehaviour which is chosen in any —The operands to certain operators are such that theycould produce a negative zero instance result, but the implementation does not support negative zeros (6.2.6.2). Appendix2 EXAMPLE J of the C standardAn example https://www.iso.org/standard/74528.html of unspecified behavior is the order in which the ($$$) arguments or to a function are http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdfevaluated. — Two declarations of the same object or function specify types that are not compatible (6.2.7).