Extending one String with another is possible through
.extend(s.chars()). However, this is better expressed using
Comparing a floating point with
!= is redundant.
cannot be compared to anything, not even itself. Use
mem::replace(&mut _, mem::uninitialized()) or
mem::replace(&mut _, mem::zeroed()) may lead to
undefined behaviour even if the value is overwritten later,
as the uninitialized value may remain in case of panic recovery.
In Rust, function pointers are assumed to not be null. Just like references,
it is expected that nullable function pointers are implemented using
Hence, checking if they are null is invalid. Instead, the wrapped
be compared to
to establish if the pointer is not present.
Encountered a syntax error.
mem::dropon a reference RS-E1010
std::mem::drop) on a reference will forget (or
drop) the reference itself, which effectively does nothing. The underlying
reference value will remain unaffected.
mem::dropon a Copy type RS-E1011
For types that implement the
std::mem::drop) effectively does nothing because the type is copied into the
function call, and the newly copied type is forgotten (or dropped).
Copy types do not have destructors; there is nothing for
std::mem::forget or (or
std::mem::drop) to do.
mem::dropon a non-Drop type RS-E1021
types that do not implement the Drop trait is a no-op.
default() method outside of the
Default trait is non-idiomatic.
It also makes deriving
Default on any subsequent types using this type impossible,
despite the presence of an implementation for
io::Read::read() are not guaranteed to process the entire buffer.
They return how many bytes were processed, which might be smaller than a given buffer’s length.
If you don’t need to deal with partial-write/read, use
Casting function pointers or closures to integer types other than
may lead to truncation of the pointer address. If this is the intended
behaviour, prefer casting to usize and then casting to the integer type
with a comment explaining the reason for the truncation.
Casting function pointers or closures to types that are neither pointers nor integers results in invalid values, introduces bugs or even causing runtime errors in the program.
std::mem::transmute(..) between a type
T and its
&T is not guaranteed to work
and is likely undefined behaviour.
That is, transmutes between a type T and *T is a common mistake and can lead to hard-to-track bugs.
default() function in the
Default trait is used to create
a default instance of the type. While implementing this, if a function
call returns the same type, it could possibly create an infinite loop
Future is a suspended computation unit which must be driven to completion by polling it. Hence, when a
Future value is ignored, it is not polled to completion, leading to any errors that might occur at the time of
Future computation execution not being handled.
This can lead to unexpected behaviour if the program assumes that the code in
Future would run.
extend() method on a
HashMap overwrites the value associated
with an existing key if it is present in the hash map being used to extend
the original one. This may not be intentional, and can lead to unexpected
behaviour of overriding values associated with existing keys in both
Transmuting integers to booleans is not guaranteed to work properly, and is likely undefined behaviour.
That is, reinterpreting bytes of an integer as a boolean can result in an invalid in-memory
representation of a
bool, which can lead to hard-to-track bugs.
Transmutes from integers to
NonZero* types can be unsound.
Transmutes work on any type provided and might cause unsoundness
when those types change elsewhere. The
only works for the appropriate types instead, restricting the transmutes
to compatible integer conversions.
Creating a null function pointer is undefined behavior.
Certain Rust types are defined to never be null.
This includes references (&T, &mut T), boxes (Box
When interfacing with C, pointers that might be
are often used, possibly requiring some convoluted
transmutes and/or unsafe code to handle conversions
to or from Rust types.
However, trying to construct or work with these invalid values is undefined behavior.
Transmuting a literal to pointer is undefined behavior.
For the cases where it is required to construct a
Rust provides the
Not all cases can be detected at the moment of this writing. For example, variables which hold a null pointer and are then fed to a transmute call aren't detectable yet.
charto reference or pointer RS-E1029
In Rust, the transmute function is used to reinterpret the bits of a value of one type as another type. Hence, both types must have the same size.
Compilation will fail if this is not guaranteed. Transmute is semantically equivalent to a bitwise move of one type into another. It copies the bits from the source value into the destination value.
Hence transmuting from float or char type to reference or pointers is considered bad in Rust because it can lead to undefined behavior. For example, transmuting a float to a pointer can lead to a null pointer exception.