The UTF-8 verifying version of nstd_core_str_[const|mut]_from_cstr_unchecked.

This module will aim to provide fast & safe interaction with the system's standard input/output/error streams.

At the top level, there should be a few functions for easily printing to stdout and reading from stdin.
Here is a sneak peek at the possible header declarations for these functions:

NSTDAPI void nstd_io_print(const NSTDChar *msg);
NSTDAPI NSTDString nstd_io_read();

These functions should also come with complimentary _line functions as well (e.g., nstd_io_read_line).

This module should also supply some lower-level modules for stdin, stdout, and stderr (nstd.io.stdin, nstd.io.stdout, and nstd.io.stderr).
Each of these streams will have their own implementations for reading/writing, for example the function for writing a full byte slice to stderr could look like this:

NSTDAPI void nstd_io_stderr_write_all(const NSTDSliceConst *bytes);

An alternative to nstd_core_mem_fill when it's fill byte is zero.

Recently I've been wanting to experiment with implementing ASM/C/C++ source code into nstd, but this is not as simple as it sounds.
Assembly can already be found in the framework, as it has been carefully added and healthily tested on each platform's hardware.

The problem with adding other languages into nstd's source is that it may cause changes in behavior. For example, the project's manifest file specifies that Rust should panic on overflow. Even if there is a way to cause unwind/abortion on overflow in C, it cannot be configured to call Rust's panic handler, which would be the desired behavior.

To fix this I am planning nstd.core.ops here.

Required C operators: ++, --, - (negate), +, -, *, /, %, <<, >>
Additional operators: ~, &, |, ^, !, &&, ||, =, +=, -=, *=, /=, %=, &=, |=, ^=, <<=, >>=, ==, !=, <, >, <=, >=
Note: The additional operators will not be implemented as it can lead to a ton of unnecessary bloat, but they will remain listed here in case this decision is overturned

// An example of what `nstd_core_ops_add_int`'s header declaration may look like.

/// Adds two numbers of type `NSTDInt`.
///
/// # Parameters:
///
/// - `NSTDInt x` - The left operand.
///
/// - `NSTDInt y` - The right operand.
///
/// # Returns
///
/// `NSTDInt z` - `x` + `y`.
NSTDAPI NSTDInt nstd_core_ops_add_int(NSTDInt x, NSTDInt y);

Because overflow check panics are library-wide, they are not required to be documented.

Whether other languages make it into nstd or not, these APIs are still useful for languages that don't provide built-in overflow checking functionality.

These functions are expected to parse a string slice as a number of (un)signed integral or floating-point type.

Here are some examples of the possible header declarations:

NSTDAPI NSTDISize nstd_core_str_const_to_isize(const NSTDStrConst *str);
NSTDAPI NSTDUInt64 nstd_core_str_const_to_u64(const NSTDStrConst *str);
NSTDAPI NSTDFloat32 nstd_core_str_mut_to_f32(const NSTDStrMut *str);

Right now, NSTDSliceMut's copy method will panic if the slice's byte lengths are not equal and it does not ensure that their element sizes are equal. The function should return error codes for these cases.

It should also take a pointer to NSTDSliceConst as the src parameter (this has been changed in the nstd.io branch).

nstd.os.macos.alloc

This module will handle low level memory allocation for macOS.

These APIs are designed around Apple's Core Foundation Allocator.

Synopsis:

NSTDAPI NSTDAnyMut nstd_os_macos_alloc_allocate(NSTDISize size);
NSTDAPI NSTDAnyMut nstd_os_macos_alloc_allocate_zeroed(NSTDISize size);
NSTDAPI NSTDErrorCode nstd_os_macos_alloc_reallocate(NSTDAnyMut *ptr, NSTDISize new_size);
NSTDAPI void nstd_os_macos_alloc_deallocate(NSTDAnyMut *ptr);

Adds the ability to get a raw pointer to the first byte in an NSTDString's buffer.

The nstd_core_mem_copy function needs a mutable raw pointer (dest: *mut NSTDByte). There is currently no way to create such a pointer in const on stable. (Well, one can of course cast a shared reference to *mut, but then writing to that would be UB.)

The copy_nonoverlapping functions inside nstd_core_mem_copy were accidentally made stable on const, but can't actually be used. We are debating whether we want to take back stabilization to avoid misuse (which we are already seeing).

Is there any issue with making nstd_core_mem_copy (and nstd_core_mem_copy_overlapping) not be const fn any more?

This will add the ability to create C string slices from a raw pointer and a length.

The declaration for these functions should look something like the following:

NSTDAPI NSTDCStrConst nstd_core_cstr_const_new(const NSTDChar *raw, NSTDUSize len);
NSTDAPI NSTDCStrMut nstd_core_cstr_mut_new(NSTDChar *raw, NSTDUSize len);

Adds the ability to create NSTDStrings from our primitive types (NSTDInt32, NSTDUSize, NSTDFloat32 and so on).

Gets the number of UTF-8 characters in an NSTDString.

nstd_core_mem_fill will have one job, and that is filling a memory buffer with a specific byte value.

These functions will add the ability to get an NSTD[CString|String|Vec]'s capacity.

Adds the ability to easily retrieve the number of bytes stored in a string slice.

This basically just means move it from core.def to the top of the crate.

However, Rust's c_char type is not yet stable in core, this will need to be done sometime after Rust 1.64.

Completes nstd.math by adding abs and pow functions for integer types (NSTD[U]Int[8|16|32|64]).

These functions will return the length of a managed C string including and excluding the null terminator.

The nstd_core_[c]str[_const]_len functions will simply return the number of characters (not bytes) in the (C) string slice.

On the other hand, nstd_core_str[_const]_byte_len will return the number of bytes in a string slice.