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

Better limit estimation in 2.x #512

Closed
ZoeyR opened this issue Mar 2, 2022 · 2 comments
Closed

Better limit estimation in 2.x #512

ZoeyR opened this issue Mar 2, 2022 · 2 comments

Comments

@ZoeyR
Copy link
Collaborator

ZoeyR commented Mar 2, 2022

Limit estimation for enums in particular can grossly underestimate the actual allocated size.

in

enum Foo {
    Bar(u8),
    Baz(SomeLargeType),
}

bincode could end up thinking only 5 bytes were claimed (4 for the discriminant, 1 for the u8), but enums take up the size of their largest variant.

Possibilites:

  • Overclaim enums for their full size
    • downside of potentially returning limit errors before actual allocated memory reaches the limit
  • Only claim for allocated types
    • stack allocated types will always blow the stack if they are too large regardless of input. Its heap allocation that can cause issues.
@Evrey
Copy link

Evrey commented Mar 5, 2022

This is also important to state in the spec: #517

As it is now, the spec implies only allocating just enough bytes for the currently set variant.

@stale
Copy link

stale bot commented May 4, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label May 4, 2022
@stale stale bot closed this as completed May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants