From 7753a3cc8acd2afa0a074d825ebf233f462827fd Mon Sep 17 00:00:00 2001 From: Geoffrey Thomas Date: Sat, 20 May 2017 12:30:51 -0400 Subject: [PATCH] other-reprs: `Option` is FFI-safe, even though it's an enum See also the improper_ctypes lint, specifically is_repr_nullable_ptr in src/librustc_lint/types.rs. --- src/other-reprs.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/other-reprs.md b/src/other-reprs.md index 02f39e3..ea42c4e 100644 --- a/src/other-reprs.md +++ b/src/other-reprs.md @@ -23,8 +23,15 @@ passed through the FFI boundary. C, and is explicitly contrary to the behavior of an empty type in C++, which still consumes a byte of space. -* DSTs, tuples, and tagged unions are not a concept in C and as such are never -FFI safe. +* DST pointers (fat pointers), tuples, and enums with data (that is, non-C-like + enums) are not a concept in C, and as such are never FFI-safe. + +* As an exception to the rule on enum with data, `Option<&T>` is + FFI-safe if `*const T` is FFI-safe, and they have the same + representation, using the null-pointer optimization: `Some<&T>` is + represented as the pointer, and `None` is represented as a null + pointer. (This rule applies to any enum defined the same way as + libcore's `Option` type, and using the default repr.) * Tuple structs are like structs with regards to `repr(C)`, as the only difference from a struct is that the fields aren’t named.