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

Add helper to ensure a structure was fully parsed #184

Open
JesusMcCloud opened this issue Nov 5, 2024 · 2 comments
Open

Add helper to ensure a structure was fully parsed #184

JesusMcCloud opened this issue Nov 5, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@JesusMcCloud
Copy link
Collaborator

No description provided.

@JesusMcCloud JesusMcCloud self-assigned this Nov 5, 2024
@JesusMcCloud
Copy link
Collaborator Author

There are different ways to go about this. From the top of my head, I can think of two:

  1. The most basic approach would be to introduce an ensureFullyParsed() function that throws if the current structure contains more children.
    • Forces you to be explicit about your intentions. Should you forget this call at the end of your parsing function and run into errors it it plain to see what is going on.
    • The need to be explicit makes it easy to screw up.
  2. Add a consumeFully() method that takes a lambda. This lambda would contain the parsing code. If, after leaving the lambda, there's still content left -> throw.
    • This layer of indirection and the fact that exisitng code related to decoding would need to be adapted with another layer of indirection makes this cumbersome and error-prone
  3. Introduce a flag to the Asn1Decodable interface that indicates whetherdoDecode() should have consumed all content.
    • We could make it default to true (because, let's be honest, this is what you want), then no changes would be needed to 99% of all parsing code. Realistically, this means that no parsing logic would need to be adapted, only cleaned up, to remove redundant checks.
    • We could not add a default value, then it would need to be explicitly set by every implementing class. Upside: no changes in behaviour. Downside: breaks existing code.

Whatever we do: having libraries compiled against different versions of Signum in the same classpath could lead to issues.

RFC from @nodh @iaik-jheher

@JesusMcCloud JesusMcCloud added the enhancement New feature or request label Jan 17, 2025
@iaik-jheher
Copy link
Collaborator

  1. with default value

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

No branches or pull requests

2 participants