On Tue, 2019-09-03 at 04:14 +0000, Dmitry Goncharov via Bug reports and discussion for GNU make 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. 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. > Please have a look at the patch in the attachment. > Tested on both big and little endian, 32 and 64 bit.
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). Your subject seems to suggest that you got a coredump: can you clarify what system / compiler / etc. that was on? Although obviously it's technically invalid to access beyond the end of a string, it typically does work without failure (I see no issues on any of my test systems for example), unless you're doing something fancy such as shared memory etc. where accessing even one byte beyond a boundary could give a segmentation fault. However, GNU make certainly doesn't do anything like that. 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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
