[Tracking Issue] Mapping of CERT C to Rust Guidelines

[felix91gr]

This is the CERT C List to clear them all.

TLDR

1. This is the full list, in the original CERT C order. Shorter tables are down below.

2. To jump to one of those:

   • List of rules that DO NOT map to Rust, and why
   • List of rules that DEFINITELY map to Rust, and how
   • Rules that map to Unsafe Rust, and how / why
   • WIP (Félix): I'm actively working out if / how they map to Rust
   • Unknown to me: please help me fill those!

3. Current Completion: 58 out of 103 (Rules that don't map to Rust are considered complete in this count).

Click to see the full list

Full List

ID	Name	Maps to Rust?	Done
PRE	Preprocessor	0-1 out of 3
PRE30	Do not create a universal character name through concatenation	No	✅
PRE31	Avoid side effects in arguments to unsafe macros Context: in C, "unsafe macro" means a macro that evaluates one of its parameters more than once or not at all. Doing so with side effects then means that those side effects are triggered either more than once, or not at all.	WIP (Félix)	⬜️
PRE32	Do not use preprocessor directives in invocations of function-like macros	No	✅
DCL	Declarations and Initialization	2 out of 8
DCL30	Declare objects with appropriate storage durations	Unsafe Only	⬜️
DCL31	Declare identifiers before using them	No	✅
DCL36	Do not declare an identifier with conflicting linkage classifications	No	✅
DCL37	Do not declare or define a reserved identifier	No	✅
DCL38	Use the correct syntax when declaring a flexible array member	No	✅
DCL39	Avoid information leakage when passing a structure across a trust boundary	Yes	⬜️
DCL40	Do not create incompatible declarations of the same function or object	No	✅
DCL41	Do not declare variables inside a switch statement before the first case label	No	✅
EXP	Expressions	5-6 out of 15
EXP30	Do not depend on the order of evaluation for side effects	No	✅
EXP32	Do not access a volatile object through a nonvolatile reference	No	✅
EXP33	Do not read uninitialized memory	Unsafe Only	⬜️
EXP34	Do not dereference null pointers	Unsafe Only	⬜️
EXP35	Do not modify objects with temporary lifetime	No	✅
EXP36	Do not cast pointers into more strictly aligned pointer types	Unsafe Only	⬜️
EXP37	Call functions with the correct number and type of arguments	No	✅
EXP39	Do not access a variable through a pointer of an incompatible type	Unsafe Only	⬜️
EXP40	Do not modify constant objects	Maybe	⬜️
EXP42	Do not compare padding data Context: it's about avoiding byte-wise comparisons, because that compares padding bits as well.	Unsafe Only	⬜️
EXP43	Avoid Undefined Behavior when using restrict-qualified pointers	No	✅
EXP44	Do not rely on side effects in operands to sizeof, _Alignof or _Generic	No	✅
EXP45	Do not perform assignments in selection statements	No	✅
EXP46	Do not use a bitwise operator with a Boolean-like operand	No	✅
EXP47	Do not call va_arg with an argument of the incorrect type	No	✅
INT	Integers	6 out of 7
INT30	Ensure that integer operations do not wrap	Yes	✅
INT31	Ensure that integer conversions do not result in lost or misinterpreted data	Yes	⬜️
INT32	Ensure that operations on signed integers do not result in overflow	Yes	✅
INT33	Ensure that division and remainder operations do not result in divide-by-zero errors	Yes	✅
INT34	Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand	Yes	✅
INT35	Use correct integer precisions	No	✅
INT36	Converting a pointer to integer or integer to pointer	Yes	⬜️
FLP	Floating Point	3-4 out of 5
FLP30	Do not use floating-point variables as loop counters	WIP (Félix)	⬜️
FLP32	Prevent or detect domain and range errors in math functions	Yes	⬜️
FLP34	Ensure that floating-point conversions are within range of the new type	Yes	⬜️
FLP36	Preserve precision when converting integral values to floating-point type	Yes	⬜️
FLP37	Do not use object representations to compare floating-point values	No	✅
ARR	Arrays	3-4 out of 6
ARR30	Do not form or use out-of-bounds pointers or array subscripts	Yes	⬜️
ARR32	Ensure size arguments for variable length arrays are in a valid range	No	✅
ARR36	Do not subtract or compare two pointers that do not refer to the same array	Unsafe Only	⬜️
ARR37	Do not add or subtract an integer to a pointer to a non-array object	WIP (Félix)	⬜️
ARR38	Guarantee that library functions do not form invalid pointers	Yes	⬜️
ARR39	Do not add or subtract a scaled integer to a pointer	No	✅
STR	Strings	0 out of 6
STR30	Do not attempt to modify string literals	No	✅
STR31	Guarantee that storage for strings has sufficient space for character data and the null terminator	No	✅
STR32	Do not pass a non-null-terminated character sequence to a library function that expects a string	No	✅
STR34	Cast characters to unsigned char before converting to larger integer sizes	No	✅
STR37	Arguments to characer-handling functions must be representable as an unsigned char	No	✅
STR38	Do not confuse narrow and wide character strings and functions	No	✅
MEM	Memory Management	2-5 out of 6
MEM30	Do not access freed memory	WIP (Félix)	⬜️
MEM31	Free dynamically allocated memory when no longer needed	WIP (Félix)	⬜️
MEM33	Allocate and copy structures containing a flexible array member dynamically	No	✅
MEM34	Only free memory allocated dynamically	WIP (Félix)	⬜️
MEM35	Allocate sufficient memory for an object Context: this is all about preventing buffer overflows	Unsafe Only	⬜️
MEM36	Do not modify the alignment of objects by calling realloc()	Unsafe Only	⬜️
FIO	Input Output	2-3 out of 13
FIO30	Exclude user input from format strings	No	✅
FIO32	Do not perform operations on devices that are only appropriate for files	WIP (Félix)	⬜️
FIO34	Distinguish between characters read from a file and EOF or WEOF	No	✅
FIO37	Do not assume that fgets() or fgetws() returns a nonempty string when successful	No	✅
FIO38	Do not copy a FILE object	No	✅
FIO39	Do not alternately input and output from a stream without an intervening flush or positioning call	No	✅
FIO40	Reset strings on fgets() or fgetws() failure	No	✅
FIO41	Do not call getc(), putc(), getwc() or putwc() with a stream argument that has side effects	No	✅
FIO42	Close files when they are no longer needed	Yes	⬜️
FIO44	Only use values for fsetpos() that are returned from fgetpos()	No	✅
FIO45	Avoid TOCTOU race conditions while accessing files	Yes	⬜️
FIO46	Do not access a closed file	No	✅
FIO47	Use valid format strings	No	✅
ENV	Environment	1 out of 5
ENV30	Do not modify the object referenced by the return value of certain functions	No
ENV31	Do not rely on an environment pointer following an operation that may invalidate it	No	✅
ENV32	All exit handlers must return normally	No	✅
ENV33	Do not call system()	Yes	⬜️
ENV34	Do not store pointers returned by certain functions	No	✅
SIG	Signals	0-4 out of 4
SIG30	Call only asynchronous-safe functions within signal handlers		⬜️
SIG31	Do not access shared objects in signal handlers		⬜️
SIG34	Do not call signal() from within interruptible signal handlers		⬜️
SIG35	Do not return from a computational exception signal handler		⬜️
ERR	Error Handling	0 out of 4
ERR30	Take care when reading errno	No	✅
ERR32	Do not rely on indeterminate values of errno	No	✅
ERR33	Detect and handle standard library errors	No	✅
ERR34	Detect errors when converting a string to a number	No	✅
CON	Concurrency	3-11 out of 13
CON30	Clean up thread-specific storage		⬜️
CON31	Do not destroy a mutex while it is locked		⬜️
CON32	Prevent data races when accessing bit-fields from multiple threads	Unsafe Only	⬜️
CON33	Avoid race conditions when using library functions	Yes	⬜️
CON34	Declare objects shared between threads with appropriate storage durations	Unsafe Only	⬜️
CON35	Avoid deadlock by locking in a predefined order		⬜️
CON36	Wrap functions that can spuriously wake up in a loop		⬜️
CON37	Do not call signal() in a multithreaded program	No	✅
CON38	Preserve thread safety and liveness when using condition variables		⬜️
CON39	Do not join or detach a thread that was previously joined or detached		⬜️
CON40	Do not refer to an atomic variable twice in an expression		⬜️
CON41	Wrap functions that can spuriously fail in a loop		⬜️
CON43	Do not allow data races in multithreaded code	No	✅
MSC	Miscellaneous	2 out of 8
MSC30	Do not use the rand() function for generating pseudorandom numbers	No	✅
MSC32	Properly seed pseudorandom number generators	Yes	⬜️
MSC33	Do not pass invalid data to the asctime() function	No	✅
MSC37	Ensure that control never reaches the end of a non-void function	No	✅
MSC38	Do not treat a predefined identifier as an object if it might only be implemented as a macro	No	✅
MSC39	Do not call va_arg() on a va_list that has an indeterminate value	No	✅
MSC40	Do not violate constraints Context: this is about not writing code that doesn't comply with the C standard.	No	✅
MSC41	Never hard code sensitive information	Yes	⬜️

[felix91gr]

Rules that do NOT map to Rust, and why

Click to see the list

ID	Name	Why not?
PRE	Preprocessor
PRE30	Do not create a universal character name through concatenation	This is just very specific to C
PRE32	Do not use preprocessor directives in invocations of function-like macros	This rule is needed in C due to how its preprocessor works. It's very C-preprocessor-specific, and doesn't map to Rust
DCL	Declarations and Initialization
DCL31	Declare identifiers before using them	Inferred types in Rust must always type-check. Not doing so results in a compile-time error. Therefore, the use case for this rule doesn't exist in Rust.
DCL36	Do not declare an identifier with conflicting linkage classifications	This is a very specific issue to C
DCL37	Do not declare or define a reserved identifier	This is a compile-time error in Rust
DCL38	Use the correct syntax when declaring a flexible array member	Structs with flexible array members are not a thing in Rust
DCL40	Do not create incompatible declarations of the same function or object	Doing this is impossible in Rust
DCL41	Do not declare variables inside a switch statement before the first case label	The semantics of C's switch statements are (fortunately) not present in Rust
EXP	Expressions
EXP30	Do not depend on the order of evaluation for side effects	Unlike for C, the evaluation order is fully defined in Rust: expressions -> expression precedence Thus, this rule isn't really needed. At least, not with the same UB-stopping urgency that it is needed for in C. Extra notes: there is a restriction lint that touches on this topic, as a precedent: mixed_read_write_in_expression
EXP32	Do not access a volatile object through a nonvolatile reference	Volatile is specific to C in this case. Furthermore, a mismatch like this would be bound by the rules of the type system, and thus be caught unless the user were to be using transmutation. Rules about transmutation, however, are not a map of this rule but their own thing.
EXP35	Do not modify objects with temporary lifetime	The borrow checker eliminates this problem
EXP37	Call functions with the correct number and type of arguments	This is enforced by the type system
EXP43	Avoid Undefined Behavior when using restrict-qualified pointers	The borrow checker gives us correct-by-construction restrict qualifications in codegen. Basically, "restrict" is part of the type system, and type checking (in particular borrow checking) enforces that its rules are always abided by.
EXP44	Do not rely on side effects in operands to sizeof, _Alignof or _Generic	This is C-specific
EXP45	Do not perform assignments in selection statements	Rust is expression-oriented. Assignments return () in Rust. Therefore the use-case for this is not really present in Rust.
EXP46	Do not use a bitwise operator with a Boolean-like operand	The type system makes usage of these operators a reasonable thing in Rust
EXP47	Do not call va_arg with an argument of the incorrect type	Variadic functions do not exist in Rust
INT	Integers
INT35	Use correct integer precisions	All primitive integer types guarantee their precision in Rust
FLP	Floating Point
FLP37	Do not use object representations to compare floating-point values	I don't think anyone does bit-by-bit comparison of floats in Rust. Nevertheless, we probably want to have a float-equality guidelines with regards to NaN, since NaN != NaN
ARR	Arrays
ARR32	Ensure size arguments for variable length arrays are in a valid range	Variable Length Arrays are not a thing in Rust
ARR39	Do not add or subtract a scaled integer to a pointer	This doesn't map quite well to Rust.
STR	Strings
STR30	Do not attempt to modify string literals	In the context of Rust, this means statics and consts. However, since it's an instance of EXP40-C: Do not modify constant objects, I'll merge the two
STR31	Guarantee that storage for strings has sufficient space for character data and the null terminator	Strings are not null-terminated in Rust and their storage space is guaranteed
STR32	Do not pass a non-null-terminated character sequence to a library function that expects a string	Strings are not null-terminated in Rust
STR34	Cast characters to unsigned char before converting to larger integer sizes	Characters in Rust are not integers. They are unicode scalar values.
STR37	Arguments to characer-handling functions must be representable as an unsigned char	Characters in Rust are not integers
STR38	Do not confuse narrow and wide character strings and functions	There's only one character type in Rust
MEM	Memory Management
MEM33	Allocate and copy structures containing a flexible array member dynamically	Flexible array members are not a thing in Rust
FIO	Input Output
FIO30	Exclude user input from format strings	Format strings are evaluated at compile time in Rust
FIO34	Distinguish between characters read from a file and EOF or WEOF	See the Read trait. EOF / WEOF cannot be acquired from them. As long as file reading operations are done through the Read trait, this should not be a concern.
FIO37	Do not assume that fgets() or fgetws() returns a nonempty string when successful	This is related to how fgets() and fgetws() were implemented and to how error handling cannot be forced by the compiler in C. In Rust, these APIs return Result<T, E>, which completely eliminates the use-case for this rule.
FIO38	Do not copy a FILE object	This is related to how the FILE object has implementation-defined behavior. This is completely C-specific, in this case.
FIO39	Do not alternately input and output from a stream without an intervening flush or positioning call	This is UB in C, due to implementation details of the stream handling APIs. The implementation of those APIs in Rust is different, so the guideline doesn't really map to it. Unsafe APIs have UB if used incorrectly. But that's a more general principle, that should be covered by a different guideline (something along the lines of "the safety invariants of Unsafe APIs being called must always be preserved")
FIO40	Reset strings on fgets() or fgetws() failure	This is related to how fgets() and fgetws() were implemented. No analog behavior exists in the file reading APIs of std in Rust.
FIO41	Do not call getc(), putc(), getwc() or putwc() with a stream argument that has side effects	This rule arises from how those APIs are implemented (as C macros), and not from a more general aspect of the situation.
FIO44	Only use values for fsetpos() that are returned from fgetpos()	This is a rule 100% derived from how those APIs work. Since those exact same APIs and implementations aren't present in Rust, this is not an issue there.
FIO46	Do not access a closed file	This is enforced by the fact that closing a file in Rust consumes the variable, invalidating any future accesses to it. Unsafe Rust, as always, could get away with doing something like this regardless, but that would be UB and should be covered by a different guideline (something along the lines of "don't extend lifetimes beyond their valid range"
FIO47	Use valid format strings	Format strings are evaluated, and therefore, validated, at compile time, in Rust
ENV	Environment
ENV30	Do not modify the object referenced by the return value of certain functions	Immutability, when required, is always enforced in Rust. I believe that Unsafe Rust could get away with doing this, jumping through some hoops. But that would lie in the vecinity of "Do not modify values whose validity invariant requires them to be immutable". Breaking validity invariants is, of course, UB.
ENV31	Do not rely on an environment pointer following an operation that may invalidate it	This is a rule that is C-specific, but could be generalized into something relevant to Rust: Make sure your code is portable, unless you have explicitly opted-in to non-portability.
ENV32	All exit handlers must return normally	Panicking doesn't have UB. Panics inside of panics will eventually abort the program.
ENV34	Do not store pointers returned by certain functions	Live References cannot be invalidated in Rust. Implementors of such libraries in Unsafe Rust must take care to not invalidate the references they create. This would be UB. It would always violate the memory model. But the rule to enforce this lies outside of the context of ENV34. It's a more general rule that must be followed.
ERR	Error Handling
ERR30	Take care when reading errno	Errno doesn't exist in Rust. But furthermore, functions that may fail wrap their result in the Result<T, E> type, which forces the caller to handle the error case if and only if it happened.
ERR32	Do not rely on indeterminate values of errno	See above
ERR33	Detect and handle standard library errors	Functions in std that may fail, wrap their result in the Result<T, E> type, which forces the caller to handle the error case whenever it happens. Thus, this rule is enforced by the compiler.
ERR34	Detect errors when converting a string to a number	See the three above. It's the same case for the conversion of strings to numbers.
CON	Concurrency
CON37	Do not call signal() in a multithreaded program	This is fully specific to C's APIs
CON43	Do not allow data races in multithreaded code	It maps, but it should be merged with CON32
MSC	Miscellaneous
MSC30	Do not use the rand() function for generating pseudorandom numbers	The APIs for generating pseudorandom numbers in core and std are currently nightly-only. I don't know if it was RNG, but IIRC something like it from the stdlib was discouraged in Rust as well, due to it not being collision resistant. I'm pretty sure it was a hash function or something.
MSC33	Do not pass invalid data to the asctime() function	This particular function doesn't exist in Rust
MSC37	Ensure that control never reaches the end of a non-void function	This is enforced by the type system
MSC38	Do not treat a predefined identifier as an object if it might only be implemented as a macro	There is no such things as a macro pointer in Rust
MSC39	Do not call va_arg() on a va_list that has an indeterminate value	Variadic functions do not exist in Rust
MSC40	Do not violate constraints Context: this is about not writing code that doesn't comply with the C standard.	The Rust compiler rejects all such programs. If a program is not valid Rust code, then it does not compile.

[felix91gr]

WIP (Félix)

These rules may or may not apply to Rust. I'm working on figuring that out.

Click to see the list

ID	Name	Why? / How?
PRE31	Avoid side effects in arguments to unsafe macros Context: in C, "unsafe macro" means a macro that evaluates one of its parameters more than once or not at all. Doing so with side effects then means that those side effects are triggered either more than once, or not at all.	In order to have side-effects, the argument to a macro must be explicitly of one of the metavariable types that could have side effects: - An expression expr, - A statement stmt, Or one of the more generic metavariables, like: - A single token tree tt - A pattern pat This in turn means that the user of a macro is well-aware when they can input side-effecting elements into a macro. Zulip thread: Macros and insertion of side-effecting metavariables
FLP30	Do not use floating-point variables as loop counters	The portability issue isn't a problem in Rust; not for basic arithmetic, at least. The issue of floats being tricky when spanning multiple orders of magnitude is still there, though. So perhaps it's a good idea to make this a rule. A final note on this: float ranges can't be iterated on. But while-loops and conditional break statements could still be used to do this. Zulip thread: Are floats ever used as loop counters?
ARR37	Do not add or subtract an integer to a pointer to a non-array object
MEM30	Do not access freed memory	This is impossible in Safe Rust. It should be possible in Unsafe, I believe. Zulip thread: Can I read something after dropping it?
MEM31	Free dynamically allocated memory when no longer needed	This rule is not about leaking memory per se, but about freeing resources after they've been used. In that sense, the Rust compiler mostly enforces this automatically. I believe there are exceptions to this, where people might std::mem::drop things manually. If that's the case, a specific rule for manual dropping should be made.
MEM34	Only free memory allocated dynamically	The Rust compiler enforces this automatically for 99.99% of scenarios As far as I'm aware, bindings are dropped as soon as their lifetime ends. If people are manually calling std::mem::drop, doing so will move the value into the function, which will make calling drop with it again impossible. However, if people really want, I believe there's a way to cheat this with Unsafe. That could merit its own rule, but the scenario feels like a bit of a stretch.
FIO32	Do not perform operations on devices that are only appropriate for files	I believe opening such devices is possible using the std::fs APIs. If so, we probably want a rule like this.

[felix91gr]

Unknown to Me

These are rules for which I don't know enough to give a verdict that I'm confident in.

Please do chip in with your expertise here!

ID	Name
	Signals
SIG30	Call only asynchronous-safe functions within signal handlers
SIG31	Do not access shared objects in signal handlers
SIG34	Do not call signal() from within interruptible signal handlers
SIG35	Do not return from a computational exception signal handler
	Concurrency
CON30	Clean up thread-specific storage
CON31	Do not destroy a mutex while it is locked
CON35	Avoid deadlock by locking in a predefined order
CON36	Wrap functions that can spuriously wake up in a loop
CON38	Preserve thread safety and liveness when using condition variables
CON39	Do not join or detach a thread that was previously joined or detached
CON40	Do not refer to an atomic variable twice in an expression
CON41	Wrap functions that can spuriously fail in a loop

[felix91gr]

Rules that DEFINITELY map to Rust, and how

Please feel free to help us in writing these guidelines!

Click to see the list

ID	Name	How?
DCL	Declarations and Initialization
DCL39	Avoid information leakage when passing a structure across a trust boundary	It seems to be technically possible to achieve, using Unsafe. Zulip thread of this discussion: How should padding bits be erased for sending? The important issue seems to be that of copying into the untrusted buffer without copying sensitive data that may lie in the uninitialized bits of the copied struct. For structs and enums, this seems to be solvable by making a type which copies everything except for the padding bits inside of it. For unions, one might want to be REALLY SURE, and hopefully prove, that you're not copying your padding. Might be impossible to safely send unions. One might want also to zero-out sensitive memory in their own processes, such that nothing sensitive is left behind after they end. That's outside the scope of our work. Zulip thread on this: Are bits erased on drop? If not, how can I ensure they are?
INT	Integers
INT30	Ensure that integer operations do not wrap	This rule has been implemented ✅
INT31	Ensure that integer conversions do not result in lost or misinterpreted data	This Guideline is being written
INT32	Ensure that operations on signed integers do not result in overflow	This rule has been implemented ✅
INT33	Ensure that division and remainder operations do not result in divide-by-zero errors	This rule has been implemented ✅
INT34	Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand	This rule has been implemented ✅
INT36	Converting a pointer to integer or integer to pointer	With modifications: - ptr2int: considered to be relatively unimportant - int2ptr: cautioned against Pointer Provenance plays a role in this Also, see: transmute: caution against int2ptr transmutation
FLP	Floating Point
FLP32	Prevent or detect domain and range errors in math functions	This is like the div by 0 rule. Should apply extensively to both floats and ints
FLP34	Ensure that floating-point conversions are within range of the new type	Same as the Integer Conversion rule
FLP36	Preserve precision when converting integral values to floating-point type	Same as the Integer Conversion rule
ARR	Arrays
ARR30	Do not form or use out-of-bounds pointers or array subscripts	In Safe Rust: - Direct addressing will panic if OOB - arr.get(index) will return None if OOB In Unsafe Rust: - arr.get_unchecked(index) is UB if OOB. So, I'd say out-of-bound indexing should be either prevented or handled properly. If using Unsafe indexing, it should be validated formally.
ARR38	Guarantee that library functions do not form invalid pointers	With modifications: - References must always be valid. - Pointers probably too? std::ptr
FIO	Input Output
FIO42	Close files when they are no longer needed	This is a good precept for life, I guess. In Rust, handling of such resources is a lot easier since their Drop implementation should close them automatically. It's still good to keep in mind, and not make a file e.g. have the 'static lifetime if that's not necessary.
FIO45	Avoid TOCTOU race conditions while accessing files	std::fs explicitly talks about TOCTOU and how to avoid it
ENV	Environment
ENV33	Do not call system()	The mapping is not exact (it doesn't involve system()): If running commands, their input must always be sanitized, and their behavior should be made portable. There is a Clippy lint that touches on this topic. We probably want a set of rules to address how system commands may be called.
CON	Concurrency
CON33	Avoid race conditions when using library functions	This problem is not as awful as it is in C, thanks to the borrow checker. However, there are certain data structures (like Rc<T>) which are not thread-safe. The trait we want to ask for is probably Send, which guarantees that copying values of the given type across threads is safe to do. Arc<T> implements this trait. We might want to ask for an even-stronger guarantee: not just safety, but impossibility of race conditions. This might require formal verification of the library being used, though, since I don't know of a mechanism to guarantee this in the compiler.
MSC	Miscellaneous
MSC32	Properly seed pseudorandom number generators	This applies to every language
MSC41	Never hard code sensitive information	This is good life advice

[felix91gr]

Maybe

I'm not sure either way for these rules.

ID	Name	Why?
EXP40	Do not modify constant objects	const items can't be modified - they are actually inlined at every point of usage, so modifying them wouldn't do a thing anyways. static items can be modified, but this is by design - some things are meant to be "global items with special case mutability" Could be an Advisory rule

[felix91gr]

Rules that map directly to Unsafe Rust

These rules are all about avoiding Undefined Behavior. Reasoning about Unsafe Rust is very hard; we will probably finish this part of the list after we finish all the others.

Click to see the list

ID	Name	Why? / How?
DCL	Declarations and Initialization
DCL30	Declare objects with appropriate storage durations	In Safe Rust, the borrow checker enforces all accesses to memory to be within the lifetime of said memory. In Unsafe, the borrow checker is not disabled. However, it is possible to use unsafe features to extend the lifetime of references (e.g. transmute or raw pointers). This is not always UB; the user must document and justify their decision to extend a lifetime, explaining why it's correct to do so. That being said, almost all of Unsafe can be used to perform a use-after-free. So it might be the case that this rule spawns multiple others. Zulip thread: Quick questions about UB
EXP	Expressions
EXP33	Do not read uninitialized memory	UB in Rust
EXP34	Do not dereference null pointers	With modifications: zero-sized accesses are Defined Behavior std::ptr safety
EXP36	Do not cast pointers into more strictly aligned pointer types	Heavily modified. Casting them is always Defined Behavior. The accesses that are performed afterwards are the ones that can cause UB. The user must make sure that whatever accesses they perform after the cast, are always correct to do. Zulip thread: Quick questions about UB
EXP39	Do not access a variable through a pointer of an incompatible type	Rust doesn't really have this idea of "compatible types" being allowed to be used like one another, not at the level that C does: For Safe Rust, we can make all conversions safe in the following way: 1. If we discourage the usage of the as operator (which we're already doing for integers), 2. Then the only conversion avenue that remains in Safe Rust is the one that the From and TryFrom traits give. 3. This conversion route is always safe, guaranteed statically by the type system. For Unsafe, however: The one avenue that allows this kind of conversion is std::mem::transmute. Transmutation is incredibly dangerous, and we probably want a handful of guidelines about it. I'd recommend we write an entire mini-chapter on transmutation.
EXP42	Do not compare padding data Context: it's about avoiding byte-wise comparisons, because that compares padding bits as well.	Byte-wise comparisons are impossible in Safe Rust. You can do so in Unsafe Rust, but this is discouraged nonetheless: there's no guarantee as to what the value of padding bits will be. Just don't do it! UCG: Padding may be a good supplementary read
ARR	Arrays
ARR36	Do not subtract or compare two pointers that do not refer to the same array	This maps to a series of guidelines. Pointers cannot be subtracted or compared in Rust. However, the same idea here applies - pointer arithmetic between pointers must only happen inside the same allocation: std::ptr->allocation I would say that every Safety rule in the ptr module probably merits its own Guideline. One rule that must be definitely be in there is that we want our offset methods to never take us to a point outside of the bounds of the object our pointer is attached to.
MEM	Memory Management
MEM35	Allocate sufficient memory for an object Context: this is all about preventing buffer overflows	This is not a problem in Safe Rust. It is possible, however, to write past a pointer's valid stride in Unsafe. Doing so is UB. Check the notes of e.g. std::ptr::write_bytes
MEM36	Do not modify the alignment of objects by calling realloc()	Slightly modified. std::ptr::realloc has a set of validity requirements that must be met. Not meeting them results in UB. Here's the list.
CON	Concurrency
CON32	Prevent data races when accessing bit-fields from multiple threads	Data races are impossible in Safe Rust. Data races are UB in Rust, and they are possible in Unsafe. If designing a concurrency library with Unsafe Rust, care must be taken to ensure data races do not happen. We might want a general rule against data races, since they are always UB.
CON34	Declare objects shared between threads with appropriate storage durations	Borrow checking makes it so usage of memory can only happen whilst its lifetime is valid. Unsafe Rust can extend lifetimes via raw pointer tricks; thus, if Unsafe is involved, care must be taken to not extend a lifetime past the point where that memory is freed.