1 unstable release
0.1.2 | Apr 22, 2019 |
---|---|
0.1.1 |
|
0.1.0 |
|
#284 in No standard library
14KB
230 lines
sysfunc-byteorder
This repository contains basic byte order support code for compile-time assessment. This was originally designed to be significantly more complex, but has instead been stripped right back to lean on spec
models for the rustc
. This now uses const fn
and macro work to present byte order for:
u8
;u16
;u32
;u64
;u128
(with feature 'enable-128').
The signed types should function in the same manner (as should floating point types, all things considered). This exists primarily to help debug and assist low level code, and to ensure that shift-based manipulators (like sysfunc-dynamac-shifty
) can function against weird processor types.
Various tricks cannot currently be employed, but the tricks here should suffice for most purposes (where the models are known but may be variable).
Functions
Order refer to Network Order (Big Endian), and not host order (unless the host is the same):
get_byte_order_128
: returns*const [u8; 16]
with bytes ranging from 0 through 15, indicating order.get_byte_order_64
: returns*const [u8; 16]
with bytes ranging from 0 through 7, indicating order.get_byte_order_32
: returns*const [u8; 16]
with bytes ranging from 0 through 3, indicating order.get_byte_order_16
: returns*const [u8; 16]
with bytes ranging from 0 through 1, indicating order.
Features
default
: enables nothing (standard behaviour for my crates);no-core
: enables#![no_core]
;enable-128
: enables 128-bit types.
#![no_core]
As #![no_core]
assumes you will either provide you own implementation, or partial implementation, there are some base requirements here. Due to the limitations imposed upstream (by Rust, see ISSUES.md), these are an unfortunate side effect. The solution is to use from_be
to trigger a platform-specific generation, which is generated against your own implementation of the conversion (which needs to happen somehow anyway -- there is no magic).
Note: Testing #![no_core]
will require ops
, option
, iter
, assert_eq!
, and potentially other things. This is one of those complicating factors.
Language Features
no-core
will require three language features: sized
, copy
, and freeze
.
Implementation requirements
If your platform is Big Endian or Little Endian then no-core
is complete (the values are hardcoded).
If your platform is not Big Endian or Little Endian then no-core
will additionally require an implementation of from_be
for u16
, u32
, and u64
. If the enable-128
feature is used then u128
will also require from_be
to be implemented as well.
Licence
This project is licensed under the ISC Licence. See LICENCE
.