Skip to content

Note that it is a bug if you can write your own better black_box #140341

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
+5 −0
Open

Note that it is a bug if you can write your own better black_box #140341

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions library/core/src/hint.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -322,6 +322,11 @@ pub fn spin_loop() {
///
/// </div>
///
/// You should not be able to write a better `black_box` than the standard library provides. If you
/// can write a function that looks like `black_box` but is more effective at hiding the value of
/// the argument from optimizations, that would be a bug and should be reported. It just would not
/// be a *security* bug.
Comment on lines +325 to +328
Copy link
Member

@the8472 the8472 Apr 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if that's quite true. For example user code might choose to use FFI and setup linking to evade LTO, I don't think std/rustc is going to jump through those kinds of hoops since it can't control linking of generic instantiations.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps "you should not be able to use other parts of the standard library to write a better..." then?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean by evading LTO. If LTO can see through black_box it's already quite non-functional for benchmarking.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A weak blackbox implementation might prevent DCE of the input but not optimizations based on properties of the output value.

You can also replace LTO with other post-link optimizations such as wasm JIT and user code taking steps avoid that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A JIT can break any black box so I'm not sure what point you are trying to make.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A JIT will have blind spots or even explicit escape hatches and you can make a targeted blackbox using those.

The point I'm making is that users may be "able to write a better black_box" under specific circumstances and the standard library won't adopt those.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A weak blackbox implementation might prevent DCE of the input but not optimizations based on properties of the output value.

that's an example where you could do better, and it would indeed be a buggy implementation that should be reported, as the docs say.

Copy link
Member

@the8472 the8472 Apr 26, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I meant that as an example for a hypothetical backend or target where that's the best we can do.
E.g. by making a value "escape" to a static we could prevent DCE but the backend lacks a way to make the value opaque because it's a single-threaded closed-world environment that has no concept of MMIO or interactions with the environment outside the abstract machine other than special IO instructions, so even volatile would get lowered to plain stores and loads.

///
/// [`std::convert::identity`]: crate::convert::identity
///
/// # When is this useful?
Expand Down
Loading