Remove struct padding macros?

[jodavies]

The struct padding macros are a bit awkward, particularly in cases with nested pre-processor variables which change the struct members, for eg:

form/sources/structs.h

Lines 1947 to 1963 in 93f976e

	#ifdef WITHFLOAT
	#if defined(WITHPTHREADS)
	PADPOSITION(50,12+3*MAXNEST,77,48+3*MAXNEST+MAXREPEAT,COMMERCIALSIZE+MAXFLAGS+4+sizeof(LIST)*17+sizeof(pthread_mutex_t));
	#elif defined(WITHMPI)
	PADPOSITION(50,12+3*MAXNEST,77,49+3*MAXNEST+MAXREPEAT,COMMERCIALSIZE+MAXFLAGS+4+sizeof(LIST)*17);
	#else
	PADPOSITION(48,12+3*MAXNEST,75,48+3*MAXNEST+MAXREPEAT,COMMERCIALSIZE+MAXFLAGS+4+sizeof(LIST)*17);
	#endif
	#else
	#if defined(WITHPTHREADS)
	PADPOSITION(50,8+3*MAXNEST,77,48+3*MAXNEST+MAXREPEAT,COMMERCIALSIZE+MAXFLAGS+4+sizeof(LIST)*17+sizeof(pthread_mutex_t));
	#elif defined(WITHMPI)
	PADPOSITION(50,8+3*MAXNEST,77,49+3*MAXNEST+MAXREPEAT,COMMERCIALSIZE+MAXFLAGS+4+sizeof(LIST)*17);
	#else
	PADPOSITION(48,8+3*MAXNEST,75,48+3*MAXNEST+MAXREPEAT,COMMERCIALSIZE+MAXFLAGS+4+sizeof(LIST)*17);
	#endif
	#endif

and it seems quite possible that the macros are not all given the correct numbers for arguments these days since they must be manually modified whenever any structs are updated.

The manual padding is not necessary with modern compilers, and the commentary around the macro definitions admits this also. Two structs have a strict size requirement (STOREHEADER, FILEINDEX) and these have explicit padding which doesn't use the macros.

I looked through by eye, I think only one struct has a member which is "out of order": SETUPPARAMETERS has a LONG after int, though there are two ints so it doesn't matter...

I ran a performance comparison with the padding disabled (simply by redefining PADDUMMY to do nothing), and measure no difference.

Any thoughts?

[vermaseren]

Much of this is from times that it did make a difference. More weird things have happened. For instance on some computers the chance was 50% that Form would run almost twice as slow than in the other 50% of the cases. The proper way to run then was to start a run. Look how fast it ran, and in the slow variety kill it and start again. Probably also a matter of even or odd times some power of two. If we cannot find any examples of the padding making a difference, it can be taken out of course. Makes things clearer, because it is way too easy to forget to update the padding when a big structure is modified.

…

On 25 Sep 2025, at 18:11, jodavies ***@***.***> wrote: The struct padding macros are a bit awkward, particularly in cases with nested pre-processor variables which change the struct members, for eg: https://github.com/form-dev/form/blob/93f976e7d32e0613e376a2348a2fb3645b9c13e9/sources/structs.h#L1947-L1963 and it seems quite possible that the macros are not all given the correct numbers for arguments these days since they must be manually modified whenever any structs are updated. The manual padding is not necessary with modern compilers, and the commentary around the macro definitions admits this also. Two structs have a strict size requirement (STOREHEADER, FILEINDEX) and these have explicit padding which doesn't use the macros. I looked through by eye, I think only one struct has a member which is "out of order": SETUPPARAMETERS has a LONG after int, though there are two ints so it doesn't matter... I ran a performance comparison with the padding disabled (simply by redefining PADDUMMY to do nothing), and measure no difference. Any thoughts? — Reply to this email directly, view it on GitHub <#715>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJPCEV6NR3JEZHZXD6V7BT3UQH45AVCNFSM6AAAAACHQBTRF2VHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYHE2DKOJUHE>. You are receiving this because you are subscribed to this thread.

[tueda]

Nowadays, compiler vendors conform to the size, layout and alignment rules specified by the system's ABI. If this is not the case, it is usually considered a bug.

On buggy systems, the padding macros may affect the alignment of structs. We can use _Alignas/alignas in C11/C++11 to guarantee proper alignment, provided that the compiler behaves correctly.