-
Notifications
You must be signed in to change notification settings - Fork 137
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
x509-cert: move to all owned types? #765
Comments
I don't really see a way to make a better certificate builder API without this. The current version of the API kind of work, but it's pretty inconvenient to use. |
attempt at RustCrypto#765
I'd prefer to see owned and no copy be peers rather than owned replacing no copy (even if owned is why got the shorter crate name). The draft changes would generate a pile of work to catch up and each could be useful to have. |
@carl-wallace as I mentioned, we can still have |
So do we want just duplicate all the types to add a I'm okay with that, just want to make sure, for example the Lines 35 to 162 in c7c1fa7
Or do I just throw a macro in there an factorize out both bodies? |
Could we have proc macros emit a second set of structures such that one set behaves the old way and one set uses owned? On Nov 26, 2022, at 11:19 AM, Tony Arcieri ***@***.***> wrote:
@baloo for now I’d say make everything owned, and circle back in *Ref types later as part of #689, which needs additional design work anyway
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Really if we want to have unified borrowed/owned types I would suggest evaluating It would allow us to define zero-copy types and owned wrappers which borrow from them. However, if we'd like to have truly heapless support as per #689, I think they are really going to need to be different data structures entirely. It may be necessary to loop in e.g. |
This has been completed, as far as I'm aware |
The
x509-cert
crate currently has a hard dependency onalloc
, but several types still have a lifetime which borrows from the input, which precludes one-pass decoding from PEM (where Base64 is decoded directly into owned types) and makes writing things like certificate builders harder.We could potentially move entirely to types which own their backing data, eliminating lifetimes from all types. We could still potentially have a corresponding set of borrowed e.g.
Ref
types (see #689), but using owned types would make usage more convenient at the cost of losing zero-copy decoding from DER bytes.The text was updated successfully, but these errors were encountered: