It indeed crashes with a core dump. I observed this on sunos/gcc when p+3 points to the next page. This should be easy to reproduce with a tool like libefence. Another way to reproduce is to run $(wildcard hello*) in a directory with thousands of files.
regards, Dmitry On Tue, Sep 24, 2019 at 1:01 PM Paul Smith <p...@mad-scientist.net> wrote: > > 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
