Identify Clippy lints suitable for creating safety-critical guidelines

[sei-dsvoboda]

This will be a table.

Column A in the table will be the current list of linters. Column B will describe how much the linter would qualify in a safety-critical standard.

Column B would be as simplas 'yes/no' or things we would want to tweak. Or a summary of the appropriate rule to cover the linter. Details TBD.

[felix91gr]

Here is a table of lints that I think work best for ensuring certain safety-critical guidelines are satisfied.

Glossary:

• UB: Undefined Behavior
• SC: Safety Critical

The third column is meant to say "Who would use it and when"

Lint	What it does	Who, when	Why
allow_attributes	Makes sure that a rule exception is in a context where that rule is being applied	Everyone using Clippy for SC contexts	To get the most out of using Clippy
arithmetic_side_effects	Ensures that all arithmetic operations are done through APIs with consistent and safe behavior. For example, 1u64.checked_div(0) gives out a None, and i8::MAX.saturating_add(100) gives out i8::MAX	Anyone	To statically eliminate a source of UB
as_conversions	Enables a collection of guards against lossy cast operations. Recommends usage of functions such as try_into	Anyone	To prevent lossy casts and dangerous coercions
as_pointer_underscore	Ensures that pointers are always cast to an explicit type	Anyone	To make pointer cast behavior more explicit
as_underscore	Ensures that the type a value is being cast to is always made explicit	Anyone	To make cast behavior more explicit
default_union_representation	Ensures union layout is always made explicit. The layout of unions is only guaranteed if the user is using repr(C)	People who need to do FFI and use union	To prevent mistakes due to inconsistent union layout across languages and compiler versions
else_if_without_else	Ensures that if ... else if ... else if branching sets are always terminated by an else branch. Required by MISRA C:2023 15.7	Anyone	To help ensure that all cases of the system are considered in such disjunctions
expect_used	Forbids the usage of expect and expect_err. Suggests the user handles all cases of their Option and Result types instead	Anyone	To avoid panicking
float_arithmetic	Makes sure floating point arithmetic is never used	People who must avoid floating point arithmetic	To avoid fp arithmetic
float_cmp_const	Disabling direct floating point equality operations. Direct float equality checks are almost never correct, due to the inherent imprecision in floating point numbers. Lint suggests to compare difference to a scale-invariant tolerance that the user deems to be adequate	Anyone	To ensure floating point comparisons are stable and consistent
fn_to_numeric_cast_any	Function pointers are pointers too, and can thus be cast into integers. Unless doing low-level function pointer manipulation, this is almost never the intention. The lint asks the user if their intention was to call the function instead	Anyone	To ensure function pointers aren't incorrectly cast instead of being called
host_endian_bytes, little_endian_bytes, big_endian_bytes	Guards against the encoding into specific endianness. When explicit endianness is important, like in FFI contexts or communication protocols, restricting the encodings used is a good way to avoid trouble	People who need to enforce a specific endianness	To ensure endianness is explicit
indexing_slicing	Ensures the user doesn't perform indexing or slicing that might panic at runtime. Lint suggests safe alternatives, like get, that make sure the cases where the indexing or slicing couldn't work are handled without panics	Anyone	To avoid panics due to incorrect indexing and / or slicing
integer_division_remainder_used	Ensuring operations that are susceptible to timing attacks, particularly the division and remainder ops, aren't used. Very useful in security-focused contexts	People working in security-critical systems	To avoid common timing attacks
lossy_float_literal	Detects lossy conversions from literals to floating point numbers. Such lossy conversions might be specially disconcerting when they happen to the left of the decimal point, such as when working with large magnitudes	Anyone	To avoid implicit problems due to floating point imprecision
multiple_unsafe_ops_per_block	Ensures every unsafe operation is put in its own unsafe block	Anyone	To try and make sure every unsafe operation is independently justified
non_zero_suggestions	Ensures the NonZero property of a value is preserved whenever possible. This is extremely useful, since NonZero values allow us to do division and remainder without extra steps. NonZero values are also very memory-efficient when combined with Option, since the compiler can reuse the bit-pattern of zero to store None	Anyone	To get the most out of using NonZero values
panic	Forbids the usage of panic	Anyone	To avoid panicking
pointer_format	Ensures no Debug prints are used to show pointer addresses. Showing pointers to the external world can be dangerous in many security-focused contexts	Anyone	To help avoid showing potentially-sensitive memory addresses
string_slice	Ensures the user does not slice nor index over UTF-8 strings. Doing so is usually ill-advised, since UTF-8 characters are rarely 1-word-length. Code that does this should be vetted; the recommended way to navigate a UTF-8 string is with iterators. Slicing can be well-formed, however, if the user first obtains the char_indices of their string, to then use them to perform the slicing operation	Anyone	To avoid panics and other hard errors that come from this
todo, unimplemented, unreachable	Forbids the usage of todo, unimplemented and unreachable; these macros should not be used in SC contexts	Anyone	To avoid panics and to make the code as explicit as possible
undocumented_unsafe_blocks	Ensures unsafe blocks are always accompanied with // SAFETY: comments that explain why they are indeed safe	Anyone	To reduce the chances of UB and to ensure safety considerations are kept documented
unwrap_in_result, unwrap_used	Forbids the usage of unwrap in a number of contexts	Anyone	To avoid panicking
wildcard_enum_match_arm	Ensures that when match is applied to an enum, all cases of the enum are explicitly handled. Forbids the usage of wildcard match arms for enums. This is recommended so that new enum variants aren't automatically matched by the wildcard arm	Anyone	To make the intent of the program more explicit

Edit: all of these were picked from the restriction category.

[felix91gr]

@sei-dsvoboda hi! I wrote them here because I didn't want to edit your spreadsheet out of the blue <3

Btw, the best lints for our use cases are broadly the ones under the restriction group. I made the table from lints I picked exclusively from that group, since those are meant for niche use cases.

The correctness lints are also of course good for Safety Critical contexts, though since those are all deny by default, just the mere usage of Clippy adds all of them to the table.

[sei-dsvoboda]

@felix91gr
Thanks for your information. I will work my way through your list next (in fleshing out the table). I've done all the linters that start with "A" so far.

[PLeVasseur]

Great to see y'all working together on this!
David (standards background) 🤝 Félix (Clippy experience) sounds like a powerful combination 👍

[sei-dsvoboda]

I have added these to the spreadsheet. I agree they are all relevant to safety-critical code.

[felix91gr]

I've moved some lints that aren't in the current lint list to another table. It looks like those might've been renamed or removed.

I've also added the Lint Group each lint belongs to, as well as a filter to focus on the lint categories that might help us most.

Currently, the filter is hiding all Deprecated, Nursery (aka broken) and Style lints :)

[GPMueller]

RE: transmute vs C++'s cast mechanisms, whether to have a guideline constraining type inference

MISRA C++ 2023

• rule 4.1.3 very generally forbids undefined behaviour and "critical unspecified behaviour", which would cover incorrect type casting (like invalid reinterpret_casting)
• there's a couple specific rules about implicit conversions, in particular for function pointers and numeric types
• rule 15.1.3 requires single-argument conversions to be marked explicit

AUTOSAR C++14

• way more explicit rules than MISRA, but roughly to the same effect
• there's rule A13-5-3 (advisory) which forbids user-defined conversion operators entirely
• rule A7-1-5 restricts the usage of auto because it hides the inferred types from the reader

I don't know Rust's type inference mechanisms, but IMO it certainly makes sense to at least recommend something against accidental implicit conversions.