You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Investigation as a part of #54 seems to suggest that ciborium links, if not to libstd, then at least to liballoc, regardless of the presence of the std feature flag. I'm unsure whether or not this is intentional; I assume that disabling the std flag in this crate is intended to disable both liballoc and libstd. I'm unsure when this regression happened (if indeed this is a regression at all), but we should see about fixing it before issuing the next release. We may also want to consider adding an alloc feature.
The text was updated successfully, but these errors were encountered:
Just one data point: I'm using ciborium through the dcaf and coset libraries without pulling in std; I'm building for thumbv7em-none-eabihf which has no std built.
Nonetheless, testing that this property is upheld is quite valuable. Something similar was done in wasmi-labs/wasmi#387, which might be useful as a template.
The ciborium crate requires alloc, so adding a feature would require changing it to not require alloc. The ciborium-io and ciborium-ll crates already have an alloc feature which seems to work as intended.
Investigation as a part of #54 seems to suggest that ciborium links, if not to libstd, then at least to liballoc, regardless of the presence of the
std
feature flag. I'm unsure whether or not this is intentional; I assume that disabling thestd
flag in this crate is intended to disable both liballoc and libstd. I'm unsure when this regression happened (if indeed this is a regression at all), but we should see about fixing it before issuing the next release. We may also want to consider adding analloc
feature.The text was updated successfully, but these errors were encountered: