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.