Add no_std support again

[stevefan1999-personal]

This PR should add a minimal level of no_std support. This is needed in order for my shellcode generation project to work...Yes it is a little bit personal but I have my own restriction of not being able to use any std features to make the code as portable as possible...and that's the sole reason no_std exist

[CensoredUsername]

Looks proper on a first overview. Do you know if there's a way to test no_std compliance so this isn't accidentally broken in the future?

[stevefan1999-personal]

Looks proper on a first overview. Do you know if there's a way to test no_std compliance so this isn't accidentally broken in the future?

That's a tricky question because most std components comes straight out of no_std (except the OS-specific mmap and the make-memory-executable bit) and if std works, so should no_std. If I interpret you right, you are referring to it as "to make sure that it just compiles under no_std specifically", right?

[CensoredUsername]

If I interpret you right, you are referring to it as "to make sure that it just compiles under no_std specifically", right?

Yeah, that is correct. Having that guarantee from the integration tests would be nice.

[Techcable]

Clippy has a useful family of lints called std_instead_of_core and std_instead_of_alloc that warn when unnecessarily using std types when alloc & core types would do.

[stevefan1999-personal]

Clippy has a useful family of lints called std_instead_of_core and std_instead_of_alloc that warn when unnecessarily using std types when alloc & core types would do.

Yes I enabled them

[wfdewith]

Yeah, that is correct. Having that guarantee from the integration tests would be nice.

Wouldn't that be as easy as just adding a step to CI with cd runtime && cargo build --no-default-features?

[domenukk]

The best way is something like cargo check --target aarch64-unknown-none -v --no-default-feature - that way it will also catch accidental std in dependencies (if there are any)