The tls_codec_derive crate currently unconditionally refers to items from stdlib. For example this line uses std::mem::size_of. Similarly this line refers to std::io::Write. These direct unconditional references makes it impossible to use tls_codec_derive from a #![no_std] crate. The code needs to be updated so that the crate can be used in a #![no_std] environment.
To attack this problem two broad techniques will be useful:
- Wherever possible replace a
std reference with either a core reference or an alloc reference. For example, std::mem::size_of can be replaced with core::mem::size_of. Presence of liballoc can be assumed, see this comment.
- For the references which are not reexported from libcore or liballoc, feature gate them on a new
std feature. For example std::io::Write is such a reference. This std feature should be enabled if the corresponding std feature in the tls_codec crate is enabled.
Ideally a failing test case should be written as well but I'm not sure if CI builds the crates in a #![no_std] environment or not. Maybe @tarcieri or @franziskuskiefer know about it.
The
tls_codec_derivecrate currently unconditionally refers to items from stdlib. For example this line usesstd::mem::size_of. Similarly this line refers tostd::io::Write. These direct unconditional references makes it impossible to usetls_codec_derivefrom a#![no_std]crate. The code needs to be updated so that the crate can be used in a#![no_std]environment.To attack this problem two broad techniques will be useful:
stdreference with either acorereference or anallocreference. For example,std::mem::size_ofcan be replaced withcore::mem::size_of. Presence of liballoc can be assumed, see this comment.stdfeature. For examplestd::io::Writeis such a reference. Thisstdfeature should be enabled if the correspondingstdfeature in thetls_codeccrate is enabled.Ideally a failing test case should be written as well but I'm not sure if CI builds the crates in a
#![no_std]environment or not. Maybe @tarcieri or @franziskuskiefer know about it.