Consider passing around Vec<ASN1Block> instead of slices in FromASN1 #2

New Issue

2018-10-23T12:38:27-07:00

mehcode commented

2018-10-23 12:38:27 -07:00

(Migrated from github.com)

This would allow for allocation-less parsing. Currently it's required to clone data from the ASN1Blocks to move it into domain objects.

acw commented

2018-10-30 11:15:02 -07:00

(Migrated from github.com)

OK, now that I'm looking at this, I'm not sure I understand your concern. Do you have an example you can share?

In particular, the library passes around slices specifically to avoid having to do deep copies. So the only thing that should be being duplicated is a ptr/start/end construct, not the ASN1Blocks within it. I did a quick check to validate this; I removed the Clone derive on ASN1Block, and it didn't appear to have much of an effect either on the library (messed with the tests, but that's it) or a little x509 library I've been building around this one. But maybe I'm missing a critical use case?

OK, now that I'm looking at this, I'm not sure I understand your concern. Do you have an example you can share? In particular, the library passes around slices specifically to avoid having to do deep copies. So the only thing that should be being duplicated is a ptr/start/end construct, not the `ASN1Block`s within it. I did a quick check to validate this; I removed the `Clone` derive on `ASN1Block`, and it didn't appear to have much of an effect either on the library (messed with the tests, but that's it) or a little x509 library I've been building around this one. But maybe I'm missing a critical use case?

mehcode commented

2018-11-05 17:22:32 -08:00

(Migrated from github.com)

I meant in the FromASN1 and ToASN1 traits. See e6c4958eb3/src/key.rs (L85-L86)

Sorry for the delay in responding. I was waiting for the ability to make my work public so I could share the issue I was having.

I either need to be able to thread a lifetime through during deserialization or be able to pop off ASN1Blocks and move the memory inside of the struct.

Also we can definitely macro this up. Would you mind me contributing some derive macros for ToASN1 and FromASN1?

I meant in the `FromASN1` and `ToASN1` traits. See https://github.com/hashgraph/hedera-sdk-rust/blob/e6c4958eb32e60f0fb6195e8daad81aca4aefaab/src/key.rs#L85-L86 Sorry for the delay in responding. I was waiting for the ability to make my work public so I could share the issue I was having. I either need to be able to thread a lifetime through during deserialization or be able to pop off ASN1Blocks and move the memory inside of the struct. --- Also we can definitely macro this up. Would you mind me contributing some derive macros for `ToASN1` and `FromASN1`?

acw commented

2018-11-14 18:09:47 -08:00

(Migrated from github.com)

OK, I get it. I'm not sure what the best way forward is, but I'm currently thinking something like a mutable iterator. Let me play around with it.

Also, I'd be happy to accept derive macros.

OK, I get it. I'm not sure what the best way forward is, but I'm currently thinking something like a mutable iterator. Let me play around with it. Also, I'd be happy to accept derive macros.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: acw/simple_asn1#2