Tim McNamara
@timclicks.dev
Trainer and consultant on the Rust programming language. Author of Rust in Action. Team climate. Walkable neighbourhoods are nice, actually.
Signal: @timclicks.01
Signal: @timclicks.01
I hope you've found this thread helpful!
If you have questions, do ask them :)
p.s. If you've discovered the thread through the algorithm, you're welcome to follow me for more info on programming with Rust and more.
If you have questions, do ask them :)
p.s. If you've discovered the thread through the algorithm, you're welcome to follow me for more info on programming with Rust and more.
November 14, 2025 at 12:59 AM
I hope you've found this thread helpful!
If you have questions, do ask them :)
p.s. If you've discovered the thread through the algorithm, you're welcome to follow me for more info on programming with Rust and more.
If you have questions, do ask them :)
p.s. If you've discovered the thread through the algorithm, you're welcome to follow me for more info on programming with Rust and more.
You may be curious why the MaybeUninit::zeroed() method doesn't require unsafe to call.
That's because it's actually safe to create uninitialized values, and to write to them, but not to read from them.
That's because it's actually safe to create uninitialized values, and to write to them, but not to read from them.
November 14, 2025 at 12:59 AM
You may be curious why the MaybeUninit::zeroed() method doesn't require unsafe to call.
That's because it's actually safe to create uninitialized values, and to write to them, but not to read from them.
That's because it's actually safe to create uninitialized values, and to write to them, but not to read from them.
What happens when you execute code with undefined behavior?
Nothing good.
In my testing, the compiler generated code that provoked the CPU to fault due to an illegal instruction.
Nothing good.
In my testing, the compiler generated code that provoked the CPU to fault due to an illegal instruction.
November 14, 2025 at 12:59 AM
What happens when you execute code with undefined behavior?
Nothing good.
In my testing, the compiler generated code that provoked the CPU to fault due to an illegal instruction.
Nothing good.
In my testing, the compiler generated code that provoked the CPU to fault due to an illegal instruction.
When you use an unsafe block, you must be sure that you understand the safety preconditions.
If you make a mistake, Rust will trust you. That's a problem, as it will make decisions about what code to generate based on the assumption that undefined behavior is impossible.
If you make a mistake, Rust will trust you. That's a problem, as it will make decisions about what code to generate based on the assumption that undefined behavior is impossible.
November 14, 2025 at 12:59 AM
When you use an unsafe block, you must be sure that you understand the safety preconditions.
If you make a mistake, Rust will trust you. That's a problem, as it will make decisions about what code to generate based on the assumption that undefined behavior is impossible.
If you make a mistake, Rust will trust you. That's a problem, as it will make decisions about what code to generate based on the assumption that undefined behavior is impossible.
That's why .assume_init() needs to be wrapped in an unsafe block.
The unsafe keyword shifts responsibility for upholding Rust's rules from the compiler to the programmer.
The unsafe keyword shifts responsibility for upholding Rust's rules from the compiler to the programmer.
November 14, 2025 at 12:59 AM
That's why .assume_init() needs to be wrapped in an unsafe block.
The unsafe keyword shifts responsibility for upholding Rust's rules from the compiler to the programmer.
The unsafe keyword shifts responsibility for upholding Rust's rules from the compiler to the programmer.
Rust's references are not allowed to be null. That's why you'll never receive a null pointer exception when you work in the language.
The &i32 type is a reference to an integer.
So, when used with &32, MaybeUninit::zeroed() essentially creates a null pointer by design.
The &i32 type is a reference to an integer.
So, when used with &32, MaybeUninit::zeroed() essentially creates a null pointer by design.
November 14, 2025 at 12:59 AM
Rust's references are not allowed to be null. That's why you'll never receive a null pointer exception when you work in the language.
The &i32 type is a reference to an integer.
So, when used with &32, MaybeUninit::zeroed() essentially creates a null pointer by design.
The &i32 type is a reference to an integer.
So, when used with &32, MaybeUninit::zeroed() essentially creates a null pointer by design.
The MaybeUninit type provides Rust programmers with a way to talk about values that might not be correctly initialized.
MaybeUninit::zeroed() fills that space with zero bits.
For many (most?) types, that's an excellent default. But...
MaybeUninit::zeroed() fills that space with zero bits.
For many (most?) types, that's an excellent default. But...
November 14, 2025 at 12:59 AM
The MaybeUninit type provides Rust programmers with a way to talk about values that might not be correctly initialized.
MaybeUninit::zeroed() fills that space with zero bits.
For many (most?) types, that's an excellent default. But...
MaybeUninit::zeroed() fills that space with zero bits.
For many (most?) types, that's an excellent default. But...
Following here is what I intended -- sorry, wrong verb :) -- but yes subscribing there would also be very appreciated.
November 12, 2025 at 9:05 PM
Following here is what I intended -- sorry, wrong verb :) -- but yes subscribing there would also be very appreciated.
p.s.s. You can help feed the algorithm by subscribing to make the numbers go up. It helps!!
November 11, 2025 at 10:59 PM
p.s.s. You can help feed the algorithm by subscribing to make the numbers go up. It helps!!
p.s. I have begun to think about how to be more active on here. Is there questions that would be useful to talk or write about?
November 11, 2025 at 10:59 PM
p.s. I have begun to think about how to be more active on here. Is there questions that would be useful to talk or write about?
It was added very recently (version 1.91.0). Try `rustup update`.
November 10, 2025 at 9:12 PM
It was added very recently (version 1.91.0). Try `rustup update`.
And if you're curious about why "deny(...)" is on every line, it's because I find that this style works best with version control.
November 10, 2025 at 3:12 AM
And if you're curious about why "deny(...)" is on every line, it's because I find that this style works best with version control.
Article with more info: www.patreon.com/posts/deny-...
November 9, 2025 at 11:34 PM
Article with more info: www.patreon.com/posts/deny-...
November 9, 2025 at 11:34 PM
Being stricter will be annoying at first. Your project won't build. It'll be slower to get the next feature out.
But remember when you were "fighting the borrow checker". It was frustrating and development slow. After a while, things got easier. After some time, you started appreciating the check.
But remember when you were "fighting the borrow checker". It was frustrating and development slow. After a while, things got easier. After some time, you started appreciating the check.
November 9, 2025 at 11:34 PM
Being stricter will be annoying at first. Your project won't build. It'll be slower to get the next feature out.
But remember when you were "fighting the borrow checker". It was frustrating and development slow. After a while, things got easier. After some time, you started appreciating the check.
But remember when you were "fighting the borrow checker". It was frustrating and development slow. After a while, things got easier. After some time, you started appreciating the check.
These warnings prevent UB:
#![deny(deref_nullptr)]
#![deny(integer_to_ptr_transmutes)]
#![deny(invalid_value)]
#![deny(invalid_from_utf8)]
#![deny(never_type_fallback_flowing_into_unsafe)]
#![deny(ptr_to_integer_transmute_in_consts)]
#![deny(static_mut_refs)]
#![deny(deref_nullptr)]
#![deny(integer_to_ptr_transmutes)]
#![deny(invalid_value)]
#![deny(invalid_from_utf8)]
#![deny(never_type_fallback_flowing_into_unsafe)]
#![deny(ptr_to_integer_transmute_in_consts)]
#![deny(static_mut_refs)]
November 9, 2025 at 11:34 PM
These warnings prevent UB:
#![deny(deref_nullptr)]
#![deny(integer_to_ptr_transmutes)]
#![deny(invalid_value)]
#![deny(invalid_from_utf8)]
#![deny(never_type_fallback_flowing_into_unsafe)]
#![deny(ptr_to_integer_transmute_in_consts)]
#![deny(static_mut_refs)]
#![deny(deref_nullptr)]
#![deny(integer_to_ptr_transmutes)]
#![deny(invalid_value)]
#![deny(invalid_from_utf8)]
#![deny(never_type_fallback_flowing_into_unsafe)]
#![deny(ptr_to_integer_transmute_in_consts)]
#![deny(static_mut_refs)]
Denying specific lints is one way to reduce this risk while also benefiting from increased protection.
November 9, 2025 at 11:34 PM
Denying specific lints is one way to reduce this risk while also benefiting from increased protection.
But, do not do this in your CI/CD system. If you do, you'll risk your build breaking at any time in the future as new warnings are added to Rust.
This is much more serious than it sounds because it'll probably happen as soon as you don't want it to.
This is much more serious than it sounds because it'll probably happen as soon as you don't want it to.
November 9, 2025 at 11:34 PM
But, do not do this in your CI/CD system. If you do, you'll risk your build breaking at any time in the future as new warnings are added to Rust.
This is much more serious than it sounds because it'll probably happen as soon as you don't want it to.
This is much more serious than it sounds because it'll probably happen as soon as you don't want it to.
Adding this attribute to the top of your crate is probably the easiest way to do promote warnings to errors:
#![deny(warnings)
Cargo also respects the RUSTFLAGS environment variable. This is the most general purpose solution.
RUSTFLAGS= -D warnings
#![deny(warnings)
Cargo also respects the RUSTFLAGS environment variable. This is the most general purpose solution.
RUSTFLAGS= -D warnings
November 9, 2025 at 11:34 PM
Adding this attribute to the top of your crate is probably the easiest way to do promote warnings to errors:
#![deny(warnings)
Cargo also respects the RUSTFLAGS environment variable. This is the most general purpose solution.
RUSTFLAGS= -D warnings
#![deny(warnings)
Cargo also respects the RUSTFLAGS environment variable. This is the most general purpose solution.
RUSTFLAGS= -D warnings
Granted, most are esoteric. But, even so, very it's easy to protect yourself from them. You ask the Rust compiler to deny building a project if a warning is triggered.
November 9, 2025 at 11:34 PM
Granted, most are esoteric. But, even so, very it's easy to protect yourself from them. You ask the Rust compiler to deny building a project if a warning is triggered.