On Wed, 2019-09-25 at 08:29 +0000, Edward Welbourne wrote: > > 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).
I suspect the issue is that sometimes we want to hash constant strings which are not allocated on the heap and may be placed in memory segments which fail if read past; it's not really possible to increase their sizes (I guess I could add "\0\0\0" to the end of all of them but...) And of course, sometimes strings are returned by the C runtime, not allocated by us (dirent etc.) so we'd have to copy them into our own larger memory before hashing. Seems not so great. I will work on avoiding the memory over-read, although Paolo did all the performance testing/improvements etc. and I don't have his infrastructure for checking it. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make