Uh oh!
There was an error while loading. Please reload this page.
Suggest _bytes versions of endian-converting methods - #149295
Merged
Merged
Conversation
rustbot
commented
Nov 25, 2025
Collaborator
rustbot has assigned @Mark-Simulacrum. Use |
Mark-Simulacrum
commented
Nov 26, 2025
Member
@bors r+ |
bors
commented
Nov 26, 2025
Collaborator
Zalathar added a commit
to Zalathar/rust
that referenced
this pull request
Nov 26, 2025
…ulacrum Suggest _bytes versions of endian-converting methods As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things. I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing. I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
Zalathar added a commit
to Zalathar/rust
that referenced
this pull request
Nov 26, 2025
…ulacrum Suggest _bytes versions of endian-converting methods As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things. I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing. I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
bors added a commit
that referenced
this pull request
Nov 26, 2025
Rollup of 19 pull requests Successful merges: - #148048 (Stabilize `maybe_uninit_write_slice`) - #148641 (Add a diagnostic attribute for special casing const bound errors for non-const impls) - #148765 (std: split up the `thread` module) - #149074 (Add Command::get_env_clear) - #149097 (num: Implement `uint_gather_scatter_bits` feature for unsigned integers) - #149131 (optimize `slice::Iter::next_chunk`) - #149190 (Forbid `CHECK: br` and `CHECK-NOT: br` in codegen tests (suggest `br {{.*}}` instead)) - #149239 (clarify float min/max behavios for NaNs and signed zeros) - #149243 (Fix typo and clarify bootstrap change tracker entry) - #149270 (implement `Iterator::{exactly_one, collect_array}`) - #149295 (Suggest _bytes versions of endian-converting methods) - #149301 (Motor OS: make decode_error_kind more comprehensive) - #149306 (bootstrap: Miri now handles jemalloc like everything else) - #149325 (rustdoc: add regression test for #140968) - #149332 (fix rustdoc search says “Consider searching for "null" instead.” #149324) - #149349 (Fix typo in comment.) - #149353 (Tidying up UI tests [3/N]) - #149355 (Document that `build.description` affects symbol mangling and crate IDs) - #149360 (Enable CI download for windows-gnullvm) r? `@ghost` `@rustbot` modify labels: rollup
Zalathar added a commit
to Zalathar/rust
that referenced
this pull request
Nov 27, 2025
…ulacrum Suggest _bytes versions of endian-converting methods As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things. I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing. I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
This was referenced Nov 27, 2025
bors added a commit
that referenced
this pull request
Nov 27, 2025
Rollup of 8 pull requests Successful merges: - #149238 (float::clamp: make treatment of signed zeros unspecified) - #149270 (implement `Iterator::{exactly_one, collect_array}`) - #149295 (Suggest _bytes versions of endian-converting methods) - #149332 (fix rustdoc search says “Consider searching for "null" instead.” #149324) - #149349 (Fix typo in comment.) - #149353 (Tidying up UI tests [3/N]) - #149355 (Document that `build.description` affects symbol mangling and crate IDs) - #149360 (Enable CI download for windows-gnullvm) r? `@ghost` `@rustbot` modify labels: rollup
Uh oh!
There was an error while loading. Please reload this page.
rust-timer added a commit
that referenced
this pull request
Nov 27, 2025
Rollup merge of #149295 - kornelski:endian_bytes, r=Mark-Simulacrum Suggest _bytes versions of endian-converting methods As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things. I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing. I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
github-actionsBot
pushed a commit
to rust-lang/rust-analyzer
that referenced
this pull request
Dec 1, 2025
Rollup of 8 pull requests Successful merges: - rust-lang/rust#149238 (float::clamp: make treatment of signed zeros unspecified) - rust-lang/rust#149270 (implement `Iterator::{exactly_one, collect_array}`) - rust-lang/rust#149295 (Suggest _bytes versions of endian-converting methods) - rust-lang/rust#149332 (fix rustdoc search says “Consider searching for "null" instead.” rust-lang/rust#149324) - rust-lang/rust#149349 (Fix typo in comment.) - rust-lang/rust#149353 (Tidying up UI tests [3/N]) - rust-lang/rust#149355 (Document that `build.description` affects symbol mangling and crate IDs) - rust-lang/rust#149360 (Enable CI download for windows-gnullvm) r? `@ghost` `@rustbot` modify labels: rollup
github-actionsBot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Jan 20, 2026
…ulacrum Suggest _bytes versions of endian-converting methods As pointed out [in this article](https://purplesyringa.moe/blog/ntoh-hton-is-a-bad-api/), the `int.to_be()`/`int.to_le()` functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things. I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (`0x12343412`) not changing. I've updated the docs to suggest `{to,from}_[lb]e_bytes()` instead. These methods use `[u8; _]` for endian-specific representations, which is a different type than the native-endian `u16`/`u32`/`u64`, and this is a type-safety improvement.
github-actionsBot
pushed a commit
to model-checking/verify-rust-std
that referenced
this pull request
Jan 20, 2026
Rollup of 8 pull requests Successful merges: - rust-lang#149238 (float::clamp: make treatment of signed zeros unspecified) - rust-lang#149270 (implement `Iterator::{exactly_one, collect_array}`) - rust-lang#149295 (Suggest _bytes versions of endian-converting methods) - rust-lang#149332 (fix rustdoc search says “Consider searching for "null" instead.” rust-lang#149324) - rust-lang#149349 (Fix typo in comment.) - rust-lang#149353 (Tidying up UI tests [3/N]) - rust-lang#149355 (Document that `build.description` affects symbol mangling and crate IDs) - rust-lang#149360 (Enable CI download for windows-gnullvm) r? `@ghost` `@rustbot` modify labels: rollup
ghaaj pushed a commit
to ghaaj/polygrammar
that referenced
this pull request
Aug 7, 2026
Rollup of 8 pull requests Successful merges: - rust-lang/rust#149238 (float::clamp: make treatment of signed zeros unspecified) - rust-lang/rust#149270 (implement `Iterator::{exactly_one, collect_array}`) - rust-lang/rust#149295 (Suggest _bytes versions of endian-converting methods) - rust-lang/rust#149332 (fix rustdoc search says “Consider searching for "null" instead.” rust-lang/rust#149324) - rust-lang/rust#149349 (Fix typo in comment.) - rust-lang/rust#149353 (Tidying up UI tests [3/N]) - rust-lang/rust#149355 (Document that `build.description` affects symbol mangling and crate IDs) - rust-lang/rust#149360 (Enable CI download for windows-gnullvm) r? `@ghost` `@rustbot` modify labels: rollup
flip1995 pushed a commit
to flip1995/rust-clippy
that referenced
this pull request
Aug 17, 2026
Rollup of 8 pull requests Successful merges: - rust-lang/rust#149238 (float::clamp: make treatment of signed zeros unspecified) - rust-lang/rust#149270 (implement `Iterator::{exactly_one, collect_array}`) - rust-lang/rust#149295 (Suggest _bytes versions of endian-converting methods) - rust-lang/rust#149332 (fix rustdoc search says “Consider searching for "null" instead.” rust-lang/rust#149324) - rust-lang/rust#149349 (Fix typo in comment.) - rust-lang/rust#149353 (Tidying up UI tests [3/N]) - rust-lang/rust#149355 (Document that `build.description` affects symbol mangling and crate IDs) - rust-lang/rust#149360 (Enable CI download for windows-gnullvm) r? `@ghost` `@rustbot` modify labels: rollup
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As pointed out in this article, the
int.to_be()/int.to_le()functions are technically returning a wrong type, because endian-specific representations of integers and Rust's always-native-endian integers are different things.I wanted to make the docs state more directly that byte swapping will result in the type having a "wrong" value, but I wasn't sure whether to delve into the special case of palindrome-like values (
0x12343412) not changing.I've updated the docs to suggest
{to,from}_[lb]e_bytes()instead. These methods use[u8; _]for endian-specific representations, which is a different type than the native-endianu16/u32/u64, and this is a type-safety improvement.