> BTW, we should revisit canaries and work further on moving them > closer to requested size. There's a chance this diff wil complicate > that.
Can switch the canary code to memcpy/memcmp (to handle unaligned canaries) and could then use the last byte as an index to the start of the canary. For larger movement, it could have a special value (like 255) meaning that there's a 4 byte length at an 8 byte offset. If you really wanted you could micro-optimize to lose only 1 canary bit, but that seems too complicated to save 7 bits of the canary. It could also sanity check the offsets based on the known minimum size of a chunk in that size class.
