Author njs
Recipients benjamin.peterson, neologix, njs, pitrou, rhettinger, skrah, tim.peters, trent, vstinner, wscullin, xdegaye
Date 2017-10-25.21:38:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1508967488.28.0.213398074469.issue18835@psf.upfronthosting.co.za>
In-reply-to
Content
> I'm not sure that it's a good idea to provide a "aligned malloc" fallback if such fallback would be inefficient. For example, we would have to overallocate the memory block not only for the requested alignement, but also allocates extra sizeof(size_t) bytes, *in each* aligned memmory block, to store the size of the alignment itself, to recover the original pointer... to finally be able to call free().

You can re-use the same bytes for padding and to store the offset. The main tricky thing is that for an alignment of N bytes you need to overallocate N bytes instead of (N-1). (In the worst case, malloc returns you a pointer that's already N-byte aligned, and then you have to advance it by a full N bytes so that you have some space before the pointer to store the offset.)

Also you want to do a little N = max(N, sizeof(whatever int type you use)) at the beginning to make sure it's always big enough, but this is trivial (and really even a uint16_t is plenty big to store all reasonable alignments). And make sure that N is a power-of-two, which guarantees that whatever value malloc returns will be shifted by at least malloc's regular alignment, which is guaranteed to be large enough to store a standard int type (on reasonable systems).
History
Date User Action Args
2017-10-25 21:38:08njssetrecipients: + njs, tim.peters, rhettinger, pitrou, vstinner, benjamin.peterson, trent, skrah, neologix, xdegaye, wscullin
2017-10-25 21:38:08njssetmessageid: <1508967488.28.0.213398074469.issue18835@psf.upfronthosting.co.za>
2017-10-25 21:38:08njslinkissue18835 messages
2017-10-25 21:38:08njscreate