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.

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

Allocate OsStrs and Paths in a Bump? #81

Open
sunshowers opened this issue Jul 15, 2020 · 4 comments
Open

Allocate OsStrs and Paths in a Bump? #81

sunshowers opened this issue Jul 15, 2020 · 4 comments

Comments

@sunshowers
Copy link

sunshowers commented Jul 15, 2020

It would be very convenient to support allocating OsStr and Path instances in a Bump.

Unfortunately the underlying byte representation isn't exposed on Windows, so we'll probably have to return Cow<'bump, OsStr> or Cow<'bump, Path> which may defeat the purpose :(

@fitzgen
Copy link
Owner

fitzgen commented Jul 16, 2020

In addition to the Windows issues you mentioned, this crate is always no_std, and therefore doesn't have access to either OsStr or Path at all.

It is probably best to implement this functionality in a small helper function outside of this crate. It should be relatively easy to write such a helper on top of Bump::alloc_slice_copy.

@sunshowers
Copy link
Author

sunshowers commented Jul 16, 2020

Thanks. Feel free to close this issue then. Would it be worth documenting this somewhere?

@fitzgen
Copy link
Owner

fitzgen commented Jul 16, 2020

Would it be worth documenting this somewhere?

this = "always no_std" or something else?

If you end up writing a crate that adds this helper, I'm happy to link to it from the README as well!

@sunshowers
Copy link
Author

sunshowers commented Jul 16, 2020

this = "always no_std" or something else?

ahh, good question! both of those things I guess? that bumpalo is always no_std and that this + the Windows issues are why alloc_os_str etc aren't present.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants