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

Some work on std::ascii #9059

Closed
wants to merge 1 commit into from
Closed

Some work on std::ascii #9059

wants to merge 1 commit into from

Conversation

Kimundi
Copy link
Member

@Kimundi Kimundi commented Sep 8, 2013

  • Marked a unsafe helper function as unsafe, added a second helper function
  • Added moving implementations

unsafe fn str_map_bytes(mut string: ~str, map: &'static [u8]) -> ~str {
// FIXME: #9058 Assuming this is faster than composed Iterators.
// If not, should probably rewrite.
do string.as_mut_buf |mut buf, len| {
Copy link
Member

Choose a reason for hiding this comment

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

This might be cleaner if one converted the string to ~[u8] and just used .mut_iter(); rather than pointer dances.

Copy link
Member Author

Choose a reason for hiding this comment

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

It would be indeed, but the function I updated there used pointer arithmetic for what I assumed to be speed reasons. I don't really know how to test such things, so I left the basic structure of the function as is.

Copy link
Member

Choose a reason for hiding this comment

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

The iterators are designed to optimize very well (they use pointers arithmetic internally); so that gives you the benefit of no unsafe code and equal (or faster) speed.

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 could just replace both str_map_bytes and str_copy_map_bytes with iterator chains if you think that would be better.

str_copy_map_bytes originally got introduced in #8231 under the name map_bytes. @SimonSapin: Any reason why you choose pointer arithmetic?

Copy link
Contributor

Choose a reason for hiding this comment

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

I wasn’t aware of vec.mut_iter(). How do you get a mutable [u8] from a string?

Copy link
Member

Choose a reason for hiding this comment

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

In this case, I think string.into_bytes() to get a ~[u8] which can be placed into a mut slot. (And then str::from_bytes_owned() at the end.)

(And yes; I think keeping the amount of unsafe code as small as possible is a good goal: less code to audit, and if there is a bug found then it'll only need to be changed in one spot.)

Copy link
Contributor

Choose a reason for hiding this comment

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

I think you’d want str::raw::from_bytes_owned to avoid the UTF-8 check. (This is safe when the map only changes bytes in the ASCII range.)

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, gonna rewrite the functions to only use unsafe to circumvent the utf8 checks.

bors added a commit that referenced this pull request Sep 9, 2013
- Marked a unsafe helper function as unsafe, added a second helper function
- Added moving implementations
@bors bors closed this Sep 9, 2013
flip1995 pushed a commit to flip1995/rust that referenced this pull request Aug 14, 2023
…lexendoo

[`manual_retain`]: add lint case for `binary_heap`

Closes rust-lang#9059

This PR adds changes to perform linting on the `binary_heap` as well, under the [manual_retain rule](https://rust-lang.github.io/rust-clippy/master/index.html#/manual_retain).

changelog: [manual_retain]: update for lint `binary_heap`
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.

4 participants