On Tue, 2019-09-03 at 04:14 +0000, Dmitry Goncharov wrote: >> sum_up_to_nul reads 4 bytes starting from the passed string 'p'. 'p' >> can have fewer than 4 bytes. Usually there more allocated space after >> 'p', which prevents this reading from manifesting itself.
Usually malloc aligns its allocations on word boundaries, since the caller typically needs that. It also typically rounds up all allocations to a whole number of words, since it can't represent the residue from a partial word in its free list. So usually the allocation ends on a word boundary, even if what was asked for didn't. Thus if the iteration that's reading four bytes at a time starts at the allocation's start, this should usually be safe. Not that it's good practice to rely on this, though ... >> This reading manifests itself visibly when 'p' points to the end of >> the allocated block of memory, such that p + 3 points to not >> allocated memory. Did the scan start from part way through an allocated string ? That could put it at a non-word-aligned offset from the allocation's start. >> Please have a look at the patch in the attachment. >> Tested on both big and little endian, 32 and 64 bit. Paul Smith (24 September 2019 18:38) replied: > I understand the issue. The reason for the "special" code here is > performance, and unfortunately the solution proposed will reduce > performance by a measurable amount (not huge but measurable). [snip] > With "normal" systems it's safe to read (only) memory beyond the end > of an array, at least up to the next word size, which is what this > code does. If you want to be able to rely on this "normal" behaviour, for the sake of the performance benefit it gives you, you need to add three to every call to malloc, so as to make it well-defined. Of course, that shall increase memory use by a measurable amount (not huge, but measurable). Eddy. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make