# `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](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`](LICENCE).