Option to use structs without tail-padding #65
Labels
Comments
inkeliz
changed the title
inkeliz
added a commit
that referenced
this issue
Aug 26, 2022
Now, it's possible (and recommended) to use `@packed()` to produce smaller encoded data. Additionally, `table` will use `@packed()` by default, and that is backward-compatible. That change also removes the `size-each` value from slice-headers, which saves 4-bytes per each dynamic array. This tag can be use in the project header, enabling it on all `inline` struct declared in the file: ``` karmem name @PACKED(); ``` This tag can be used to enable/disable `@packed()` for each `inline`: ``` struct Foo inline @PACKED(true) { ... } ``` If the document is using `@packed(true), it's possible to opt-out, using `@packed(false)` for specific struct: ``` struct Foo inline @PACKED(false) { ... } ``` There's no reason to use `@packed(false)`, except from compatibility reasons, for projects releases before this patch. Closes #71, #65 Fixes #32 Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
inkeliz
added a commit
that referenced
this issue
Aug 26, 2022
Now, it's possible (and recommended) to use `@packed()` to produce smaller encoded data. Additionally, `table` will use `@packed()` by default, and that is backward-compatible. That change also removes the `size-each` value from slice-headers, which saves 4-bytes per each dynamic array. This tag can be use in the project header, enabling it on all `inline` struct declared in the file: ``` karmem name @PACKED(); ``` This tag can be used to enable/disable `@packed()` for each `inline`: ``` struct Foo inline @PACKED(true) { ... } ``` If the document is using `@packed(true)`, it's possible to opt-out, using `@packed(false)` for specific struct: ``` struct Foo inline @PACKED(false) { ... } ``` There's no reason to use `@packed(false)`, except from compatibility reasons, for projects releases before this patch. Closes #71, #65 Fixes #32 Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
inkeliz
added a commit
that referenced
this issue
Aug 26, 2022
Now, it's possible (and recommended) to use `@packed()` to produce smaller encoded data. Additionally, `table` will use `@packed()` by default, and that is backward-compatible. That change also removes the `size-each` value from slice-headers, which saves 4-bytes per each dynamic array. This tag can be use in the project header, enabling it on all `inline` struct declared in the file: ``` karmem name @PACKED(); ``` This tag can be used to enable/disable `@packed()` for each `inline`: ``` struct Foo inline @PACKED(true) { ... } ``` If the document is using `@packed(true)`, it's possible to opt-out, using `@packed(false)` for specific struct: ``` struct Foo inline @PACKED(false) { ... } ``` There's no reason to use `@packed(false)`, except from compatibility reasons, for projects releases before this patch. Closes #71 Closes #65 Fixes #32 Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
inkeliz
added a commit
that referenced
this issue
Aug 26, 2022
Now, it's possible (and recommended) to use `@packed()` to produce smaller encoded data. Additionally, `table` will use `@packed()` by default, and that is backward-compatible. That change also removes the `size-each` value from slice-headers, which saves 4-bytes per each dynamic array. This tag can be use in the project header, enabling it on all `inline` struct declared in the file: ``` karmem name @PACKED(); ``` This tag can be used to enable/disable `@packed()` for each `inline`: ``` struct Foo inline @PACKED(true) { ... } ``` If the document is using `@packed(true)`, it's possible to opt-out, using `@packed(false)` for specific struct: ``` struct Foo inline @PACKED(false) { ... } ``` There's no reason to use `@packed(false)`, except from compatibility reasons, for projects releases before this patch. Closes #71 Closes #65 Fixes #32 Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
inkeliz
added a commit
that referenced
this issue
Aug 26, 2022
Now, it's possible (and recommended) to use `@packed()` to produce smaller encoded data. Additionally, `table` will use `@packed()` by default, and that is backward-compatible. That change also removes the `size-each` value from slice-headers, which saves 4-bytes per each dynamic array. This tag can be use in the project header, enabling it on all `inline` struct declared in the file: ``` karmem name @PACKED(); ``` This tag can be used to enable/disable `@packed()` for each `inline`: ``` struct Foo inline @PACKED(true) { ... } ``` If the document is using `@packed(true)`, it's possible to opt-out, using `@packed(false)` for specific struct: ``` struct Foo inline @PACKED(false) { ... } ``` There's no reason to use `@packed(false)`, except from compatibility reasons, for projects releases before this patch. Closes #71 Closes #65 Fixes #32 Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
inkeliz
added a commit
that referenced
this issue
Aug 28, 2022
Now, it's possible (and recommended) to use `@packed()` to produce smaller encoded data. Additionally, `table` will use `@packed()` by default, and that is backward-compatible. That change also removes the `size-each` value from slice-headers, which saves 4-bytes per each dynamic array. This tag can be use in the project header, enabling it on all `inline` struct declared in the file: ``` karmem name @PACKED(); ``` This tag can be used to enable/disable `@packed()` for each `inline`: ``` struct Foo inline @PACKED(true) { ... } ``` If the document is using `@packed(true)`, it's possible to opt-out, using `@packed(false)` for specific struct: ``` struct Foo inline @PACKED(false) { ... } ``` There's no reason to use `@packed(false)`, except from compatibility reasons, for projects releases before this patch. Closes #71 Closes #65 Fixes #32 Signed-off-by: Inkeliz <inkeliz@inkeliz.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, Karmem is one mixed of packed and unpacked. It doesn't have padding between fields, but have one "tail-padding", one padding at the end of the struct, that enforces the content to have alignment of 8 bytes.
The text was updated successfully, but these errors were encountered: