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 support for UInt128 (and UUID) #1948

Open
cmackenzie1 opened this issue Feb 22, 2024 · 1 comment
Open

Add support for UInt128 (and UUID) #1948

cmackenzie1 opened this issue Feb 22, 2024 · 1 comment

Comments

@cmackenzie1
Copy link

cmackenzie1 commented Feb 22, 2024

Today, a UUID can be represented in capnproto using the following ways:

  • :Text, requiring 8-byte pointer + 36 bytes (40 bytes total)
  • :Data, requiring 8-byte pointer + 16 bytes (24 bytes total)
  • 2x:UInt64 representing the lower 64 bits and upper 64 bits. (16 bytes total), but requires consumers to convert it properly.

It would be great if capnproto supported :UInt128 or a native :Uuid type to represent this data using only 128 bits (16 bytes).

@kentonv
Copy link
Member

kentonv commented Feb 26, 2024

This has been discussed before but there is some awkwardness. Currently, all integer types are aligned to their size. Should UInt128 be aligned? Well, practically speaking, it would be pretty hard to achieve that since Cap'n Proto objects in general are only aligned to 64 bits, and the underlying memory allocator probably is too. But, some people who have requested a UInt128 type actually do want it to be 128-bit aligned, for use in vector instructions that require this.

If UInt128 is only 64-bit aligned, it may be easier to implement, but it's still awkward in a different set of ways. It would have to work differently from all the other integer types.

Another solution that has been floated is the idea of "inline structs". Then you cloud declare a UUID struct with two UInt64 members, and inline it into other structs for efficiency. A much more general solution. But also a lot more work to implement, obviously.

In any case, no one is jumping to work on any of these, so we're probably stuck with using a pair of UInt64s, which, while ugly, has worked out fine in my experience.

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