It sums to   50% * 1 + 25% * 2 + 12.5% * 4 + ... = .5 + .5 + .5 + ... Worse:   So a 64 KiB SRAM or heap in the SRAM would for a naximum alignment of 32 KiB and actually stored 32-bit values on average have 7x the amount of alignment: 28 bytes instead of 4 bytes.   For a maximum alignment of 128 bytes, it would be 3x or 12 bytes.   -----Ursprüngliche Nachricht----- Von:Marc Edouard Gauthier via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 31.10.2025 18:08 Betreff:Re: [std-proposals] realloc(3) An:std-proposals_at_[hidden]; CC:Marc Edouard Gauthier <MarcEdouard.Gauthier_at_[hidden]>; Bo Persson wrote: > On 2025-10-31 at 11:41, Marcin Jaczewski via Std-Proposals wrote: > > Would it be possible to recover this information from the pointer > > itself? If it had alignment to some specific limit then the allocator > > is required to return the same on the new pointer. > > It could sometimes have "false positives" but overall it probably > > should not have a negative impact on total memory usage. > > I guess it would be more than "sometimes". Assuming that your very first > allocation from a fresh heap happens to be page aligned, what is its "true" > alignment? On average, my guess is everything would be twice too much aligned, either creating a huge amount of fragmentation or taking up twice the allocation space depending on implementation. A pointer aligned to bit N has a 50% probability of being aligned to bit N+1 (twice the expected alignment), 25% aligned to N+2 (4 times expected), etc... Summing this converges on average to twice the overall expected alignments. Marc -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals