On Fri, May 15, 2020 at 8:00 PM Philippe Verdy <verdyp@gmail.com> wrote:
> Le ven. 15 mai 2020 à 17:06, Francisco Olarte <folarte@peoplecall.com> a écrit :
>> That "prepadding" is, IMNSHO, an invention of yours.
> No, "prepadding" is what happens to align a new added field to respect its alignment contraint (i.e. determining its starting offset). "postpadding" is never needed anywhere for any type (independantly of their alignment constraint or usable size).
No. You, Philippe Verdy, define prepadding as "what happens.....". It
is not a widely used and recognized term.
> struct f1 { int a; char b; }
> then its sizeof should still be 5, its alignof should be 4.
IIRC I sent you a program proving it was not on a similar thing, but
let do it again:
<<<<
$ cat kk.c
#include <stdio.h>
struct f1 { int a; char b; };
int main(int ac, char **av) {
printf("%d\n", (int)sizeof(struct f1));
return 0;
}
$ gcc kk.c
$ ./a.out
8
>>>>
As much as I may respect your opinion, I'll trust gcc over you here.
And I show my code, not limit myself to "it should do this or that".
Well, to be fair, I do not know if it SHOULD be 5, but I know it IS 8.
> In old C, there was only sizeof() documented (and legacy memory allocators like malloc/calloc did not care about alignment constraints)
I can assure you they cared. I've worked with old, preansi, compilers
on machines with weird align requirements and malloc always took care
of not returning unaligned pointers. AAMOF they normally were OVER
aligned.
THat's the trick they used to avoid bugs: overaligning when it is not needed. But using a static alignment to some fixed multiple (e.g. 8), which porove to be insufficient (e.g. for requesting pagesize alignment).
But C++ changed that for the "new(pool)" operator that levies this restriction and allows programmers to use pools with lower or higher requirements.
The result you get above is by forcing the structure to be aligned with itself in a row, assuming its sizeof should be enough to create arrays, i.e. the struct is only followed by itself, so forcing it be be padded unconditionally, when in fact padding is only necessary for the following type that may need it, whatever type it could be! Such variable padding never depends on the first type in a row, only on the next type; each type has an intrinsic prepadding required for its own alignment, but never needs any post-padding (except unused bits in the last bitfield members to fill bytes, because siseof() can only return an integer and the C/C++ memory model can only count full bytes).
Regarding pointers, they may not always be aligned with byte boundaries: there does exist platfoms with bit-level addresses ignoring all byte boundaries, and capable of handling words with variable bit sizes not limited to multiples of full bytes (they are commonly found in microcontrolers, but also in some microarchitectures).
I can easily predict that these platform will appear and will be widely used for very high-speed computing, when parallel buses will no longer work reliably but serial links will be everywhere (in addition to removal of synchronization with a fixed clock) simply because this will be more efficient, faster, and will use less energy. At that time we'll say goodbye to bytes (except locally in the same chip or for emulating legacy instruction sets), to welcome variable size frames! I'm not saying we'll see again 6-bit bytes or 9-bit bytes. But already dynamic RAM is serial (no longer using parallel buses) for faster performance and reliability and allowing longer connections with less restrictions on clock rates and higher scalability. And the same starts appearing for storage.
If the data units are just bit aligned, what is the interest of all those old forced paddings when they are not even needed on today's architectures, and which are incorrectly placed and reduce the flexibility of the language? If all alignement is removed, the byte size of at least 1 bit would disappear (even if "char" is kept at 8 bit minimum), the basic integer unit will be the boolean, and every integer type could become just particular bitfields, with no padding ever needed anywhere for data structures (only needed for some external legacy interfaces and things like virtual memory paging that require much larger units than just single byte boundaries or few-bytes boundaries as was implemtend in legacy malloc/calloc in order to ignore the problem).
all those paddings cripple the performance with no benefit; any way to reduce them as much as possible, and notably when they are not needed at all is a "win". The final way to eliminate them completely will be to have bit-addressable memory and all types defined only by bit boundaries (what will then be the meaning of the "sizeof" operator of C/C++ if it returns only rounded sizes to an arbitrary multiple of full bytes only? Do you still think that C/C++ can correctly describe all kind of binary encoded data, and with strong typing for C++?)
