Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support #![no_std] without liballoc #58

Open
tarcieri opened this issue May 21, 2020 · 4 comments
Open

Support #![no_std] without liballoc #58

tarcieri opened this issue May 21, 2020 · 4 comments

Comments

@tarcieri
Copy link

tarcieri commented May 21, 2020 •
edited

I'd like to be able to use is_nfc_quick()/is_nfd_quick() in a context where liballoc isn't available.

It looks like the only thing linking liballoc right now is tinyvec. Would it be possible to make tinyvec into an optional dependency?
tarcieri pushed a commit to iqlusioninc/veriform that referenced this issue May 21, 2020
@tony-iqlusion
rust: ensure encoded/decoded strings are ASCII
b08278d 
This is a stopgap until the issue of Unicode normalization can be
properly addressed (e.g. should we check strings are NFC or NFD?)

Furthermore, the `unicode-normalization` crate doesn't support `no_std`
environments (sans liballoc yet):

unicode-rs/unicode-normalization#58

Ensuring all strings are ASCII, while perhaps overly restrictive for
now, will ensure all documents produced today are canonical in a way
that's forward compatible with canonical Unicode.
@tony-iqlusion tony-iqlusion mentioned this issue May 21, 2020
Merged
@Manishearth
Copy link
Member

tinyvec is necessary because theoretically decompositions and compositions can map to an unbounded number of decomposed # code points. There's probably a small practical limit in what the composition data allows though

@tarcieri
Copy link
Author

tarcieri commented May 22, 2020 •
edited

There's probably a small practical limit in what the composition data allows though

Perhaps tinyvec::ArrayVec could work? (or could be used on no_std w\o alloc at least)

@Manishearth
Copy link
Member

Sure, PRs welcome. Ideally something that switches between arrayvec and a non panicky variant

@tarcieri
Copy link
Author

...arrayvec and a non panicky variant

Oh, now I see ArrayVec doesn't have any fallible APIs and always panics on overflow. That's not great.

Elsewhere I use heapless::Vec which does provide fallible APIs, and a trait like this to abstract over heapless::Vec and heap-based data structures (really wish something like this were in core):

https://docs.rs/veriform/0.1.0/veriform/derive_helpers/trait.TryExtend.html

@tarcieri tarcieri mentioned this issue Oct 9, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@tarcieri @Manishearth