| Age | Commit message (Collapse) | Author |
|---|
|
This adds a build.rs to byteorder that will set a conditional compilation
flag automatically if the current Rust compiler supports 128-bit integers.
This makes the i128 feature itself a no-op. We continue to allow the
feature to be supplied for backwards compatibility.
Addresses https://github.com/TyOverby/bincode/issues/250
|
|
Fixes #127
|
|
|
|
Our dev-dependencies already pushed us over the minimum Rust version
supported (1.12.0), so we continue with the status quo of only testing
on stable/beta/nightly, but ensure that we continue to build on Rust
1.12.0.
|
|
Closes #129
|
|
Closes #129
|
|
PR #128
|
|
We no longer need to enable the i128 Rust feature, since it
is stabilized. We leave byteorder's i128 feature in tact to
preserve compilation on Rust 1.12.
|
|
|
|
|
|
We should have done this from the start. Everything can be accomplished
via pointer casts. Benchmarks show negligible differences.
|
|
|
|
|
|
Since nearly 2 years, there is a depcrated attribute, which can be used
https://github.com/rust-lang/rfcs/blob/master/text/1270-deprecation.md
|
|
|
|
This removes the `unsafe` annotation from
`read_{f32,f64}_into_unchecked` and deprecates the methods because the
`unchecked` name is no longer appropriate. We in turn add
`read_{f32,f64}_into` methods.
|
|
|
|
See also #105
Fixes #103
|
|
|
|
This is the mirror commit to https://github.com/rust-lang/rust/pull/46012
|
|
The similar `big_endian` tests were using an offset to read from the
end of the written `u64`, but the `native_endian` tests were reading
directly, just like the `little_endian` tests. That's of course only
correct when the target actually is little endian.
That `big_endian` offset is now sliced directly, instead of cloning into
another vector, and then this logic is also used in the `native_endian`
test, depending on the current `#[cfg(target_endian)]`.
Fixes #102.
|
|
As a consequence, this also introduces methods for doing endian
conversion on slices in-place.
|
|
In the long ago, "new" referred to the "new I/O module" after I/O reform
in the pre-1.0 days.
|
|
This commit builds on PR #91 by @newpavlov to add methods to the ByteOrder
trait that permit serializing/deserializing contiguous sequences of
integers to/from byte buffers.
|
|
|
|
|
|
Closes #63
|
|
Thanks @le-jzr!
|
|
This commit modifies the existing read_f32/read_f64 methods to
guarantee their safety by returning NaNs when signaling NaNs are
detected.
Fixes #71
|
|
|
|
Unsigned integer types were given for the signed functions of the
ByteOrder trait
|
|
The trait has default implementations around read_int/read_uint to keep
all existing instances working without changes, but implementations can
implement something more optimal if needed.
|
|
|
|
Adds the following methods to the `ByteOrder` trait:
* `read_{i128, u128}`
* `write_{i128, u128}`
* `{read_uint,read_int,write_uint,write_int}128`
Adds the following methods to the `ReadBytesExt` trait:
* `read_{i128, u128}`
* `{read_uint, read_int}128`
Adds the following methods to the `WriteBytesExt` trait:
* `write_{i128, u128}`
* `{write_uint, write_int}128`
And finally, add tests and benchmarks for i128 support.
Fixes #65
|
|
|
|
Updates #75
Updates #76
|
|
Fixes #69
Updates #76
|
|
|
|
|
|
|
|
|
|
|
|
This adds trait bounds to ByteOrder for all the traits that can
automatically be derived. Next, it derives them all for BigEndian and
LittleEndian. The exception is Default, which cannot be derived for
enums, and it is explicitly implemented as unreachable.
Fixes #52.
|
|
|
|
|
|
Fixes #57
|
|
This allows byteorder to be used in a no_std context.
|
|
Instead of casting pointers, we do a proper unaligned load using
copy_nonoverlapping.
Benchmarks appear unaffected on Linux x64.
|
|
|
|
Network byte order is defined by [RFC 1700][1] to be big-endian, and is
referred to in several protocol specifications. This type is an alias
of BigEndian. This alias can be used to make it more clear why you're
using a particular byte order in code, if you are implementing a
specification that refers to network byte order.
[1]: https://tools.ietf.org/html/rfc1700
|
