https://bugs.kde.org/show_bug.cgi?id=433859
--- Comment #1 from Paul Floyd <pjfl...@wanadoo.fr> --- I also recently noticed that C23 will probably add new versions of free (free_sized and free_aligned_sized but no free_aligned). As I see it, these are both optional and a conforming implementation can just call free. But it's UB to use the wrong size or alignment. Mixing aligned_alloc/free_sized and plain malloc family/free_aligned_sized is not allowed. >From a memcheck perspective there are a few issues. The main one that I see is where to store all this info. We currently use a 2 bit bitfield in MC_Chunk to encode malloc/new/new[]/custom. This isn't too bad for 64bit platforms, but it does limit the block size on 32bit. Now we need malloc, new and new[] which are mutually exclusive. I don't think that we need to encode sized since pretty much by definition all alocations are sized. That means we need 2 more bits to encode custom and aligned (there's a bugzi somewhere that asks for custom to also work for new/new[]). I haven't looks but I imagine that we also need to store the alignment somewhere. To be safe that means a whole register word field. So on 32bit that means adding 2 (or 1 with some squeezing) RegWords to MC_Chunk. -- You are receiving this mail because: You are watching all bug changes.
