From: Junio C Hamano Date: Thu, 08 Sep 2016 17:03:51 GMT Subject: Re: [PATCH v3 2/3] Introduce a function to run regexec() on non-NUL-terminated buffers Message-ID: In-Reply-To: <94ee698b2736929d37640012a1b1735b134dd3d6.1473321437.git.johannes.schindelin@gmx.de> Johannes Schindelin writes: > We just introduced a test that demonstrates that our sloppy use of > regexec() on a mmap()ed area can result in incorrect results or even > hard crashes. > > So what we need to fix this is a function that calls regexec() on a > length-delimited, rather than a NUL-terminated, string. > > Happily, there is an extension to regexec() introduced by the NetBSD > project and present in all major regex implementation including > Linux', MacOSX' and the one Git includes in compat/regex/: by using > the (non-POSIX) REG_STARTEND flag, it is possible to tell the > regexec() function that it should only look at the offsets between > pmatch[0].rm_so and pmatch[0].rm_eo. > > That is exactly what we need. Yes, that is good. > Since support for REG_STARTEND is so widespread by now, let's just > introduce a helper function that uses it, and fall back to allocating > and constructing a NUL-terminated when REG_STARTEND is not available. I do not think this fallback is good; we do ship a compat/ fallback that does support REG_STARTEND and you'd want to use that. Not having the copying fallback means you do not even have to worry about the size+1 overflow and fix it with xmallocz() ;-)