Skip to content

Introduce LTC_NO_STRUCT_PADDING.#757

Open
sjaeckel wants to merge 1 commit intodevelopfrom
no-struct-padding
Open

Introduce LTC_NO_STRUCT_PADDING.#757
sjaeckel wants to merge 1 commit intodevelopfrom
no-struct-padding

Conversation

@sjaeckel
Copy link
Copy Markdown
Member

@sjaeckel sjaeckel commented May 4, 2026

Pulled out from #751

#751 (comment)

The only exception is the LTC_NO_STRUCT_PADDING part, which I would suggest moving into a separate PR and perhars discuss pros/cons there. I have doubts whether it will work as expected, especially the change from ulong64 dummy[8] to void *padding[8]. In my opinion, this goes in the wrong direction as the reserved area becomes platform-dependent: 64 bytes vs. 32 bytes, depending on the pointer size.

Directly use it in `ltc_rsa_op_parameters`.

Signed-off-by: Steffen Jaeckel <s@jaeckel.eu>
@sjaeckel
Copy link
Copy Markdown
Member Author

sjaeckel commented May 5, 2026

I have doubts whether it will work as expected, especially the change from ulong64 dummy[8] to void *padding[8]. In my opinion, this goes in the wrong direction as the reserved area becomes platform-dependent: 64 bytes vs. 32 bytes, depending on the pointer size.

That's indeed going to become platform-dependent, but struct sizes always are as soon as they contain platform-dependent types like int or pointer types.

pahole says this:

                                                                64bit      |        32bit
                                                                           |
struct ltc_rsa_op_parameters {                                             | 
        ltc_rsa_parameters         params;               /*     0    16 */ | /*     0    12 */
        int                        padding;              /*    16     4 */ | /*    12     4 */
        int                        wprng;                /*    20     4 */ | /*    16     4 */
        prng_state *               prng;                 /*    24     8 */ | /*    20     4 */
        union {                                                            | 
                struct {                                                   | 
                        const unsigned char  * lparam;   /*    32     8 */ | /*    24     4 */
                        long unsigned int lparamlen;     /*    40     8 */ | /*    28     4 */
                } crypt;                                 /*    32    16 */ | /*    24     8 */
                void *             padding[8];           /*    32    64 */ | /*    24    32 */
        } u;                                             /*    32    64 */ | /*    24    32 */
                                                                           |
                                 /* size: 96, cachelines: 2, members: 5 */ | /* size: 56, cachelines: 1, members: 5 */
                                 /* last cacheline: 32 bytes */            | /* last cacheline: 56 bytes */
};                                                                         

The idea was to pad the struct up to an even size, e.g. a multiple of 32 bytes, and currently I only did that for x86_64, so we should
a) decide whether this makes sense or whether we should simply pad with some members of ulong64
and if we want to pad up to a specific size
b) decide what value to pad up to
c) do this for 32bit archs as well

Does that make sense?

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

Successfully merging this pull request may close these issues.

1 participant