Skip to content
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.

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

Null value opts for shm #1241

Merged

Conversation

yellowhatter
Copy link
Contributor

Some null value optimizations to equalize SHM data structures for zenoh-c

1usize << self.pow
pub fn get_alignment_value(&self) -> NonZeroUsize {
// SAFETY: this is safe
unsafe { NonZeroUsize::new_unchecked(1usize << self.pow) }
Copy link
Member

Choose a reason for hiding this comment

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

AllocAlignment::new() takes pow: u8 that returns Ok if pow < 64.
1usize << self.pow may overflow in case usize is 32bit.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Fixed through usize::BITS as @wyfo suggested

Copy link
Contributor

Choose a reason for hiding this comment

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

By the way, you could maybe remove this unsafe according to https://godbolt.org/z/c66j343Eq

Copy link
Contributor Author

@yellowhatter yellowhatter Jul 17, 2024

Choose a reason for hiding this comment

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

@wyfo my understanding is:

  1. Fist of all, 1usize << pow is evaluated, and it's result is usize. An overflow might happen here, which will panic on Debug and be UB on Release (UB because it is processor-defined)
  2. In NonZeroUsize::new compiler knows that FOR TARGET ARCHITECTURE any shift operation applied to 1usize constant at step 1 will always give nonzero result, even in case of overflow in Release. It means that for TARGET ARCHITECTURE a check may be elided, but for other architectures this might be wrong and check assembly will be generated.

As long as the whole AllocAlignment structure guarantees that pow will not cause overflow, we'd better use unsafe unchecked version

@Mallets Mallets merged commit 7f8b854 into eclipse-zenoh:dev/1.0.0 Jul 18, 2024
10 of 12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants