GNOME Bugzilla – Bug 706880
sysmem: Alignment has to be kept when copying
Last modified: 2016-04-20 06:29:09 UTC
+++ This bug was initially created as a clone of Bug #705678 +++ When copying a system memory with an offset, offset 0 of the copy should have the same alignment as the original data had. Not the same alignment as offset 0 of the original data.
I am not sure if I really understand this bug. Jan said in comment #6 of bug #705678 , which was the reason for cloning this aiui: > Yes, the new memory block will be aligned. The data within it > may not have the same alignment after the copy - for example, > copy from a buffer containing uint32's with an offset of > 3 - the new memory won't have aligned uint32s where the old > buffer did. Ok, so the second uint32 wouldn't be aligned any more, but why would one copy data from offset 3 anyway if the data is processed in units of 4 bytes? How does one determine what the correct alignment is in this case? e.g. if we have 4096 uint32 and we copy data from offset 4094*4 + 3, what should be the alignment of the new &data[1] ? Conversely, often one may want to explicitly achieve a new clean alignment when copying (and existing code might in fact rely on this behaviour). Example: a demuxer or parser where we have 7 bytes of headers, and then follows some payload, and we want the payload to be aligned nicely.
None of it makes sense to me any more. I think we should just mark WONTFIX
Agreed