On 4/21/23 02:45, Alejandro Colomar wrote:
> Hi Siddhesh,
> 
> It seems the glibc manual doesn't cover REG_STARTEND.  We're having
> some discussion about it, while we're improving the manual page, and
> we have some slight disagreement about what are the constraints for
> nmatch and pmatch when REG_STARTEND is specified.
> 
> Since this is a BSD extension, not in POSIX, we can't refer to the
> standard.  And since glibc doesn't document it, I can't know for
> sure your intention.
> 
> I'm not sure how much we should rely on implementation details, and
> if those will hold forever, or _FORTIFY_SOURCE and the like are
> allowed to constrain some current details.
> 
> The discussion is in this thread, if you want to read it entirely:
> <https://lore.kernel.org/linux-man/09bda4f5-ab6f-a369-ad36-0779dc3749b4@gmail.com/T/#m7dd7771072df3be97bc831f581dc7bfea684197d>
> 
> The question is:
> 
> If REG_STARTEND was specified _and_ REG_NOSUB was also specified,
> regexec(3) will read from pmatch[0] and will effectively ignore
> nmatch (the number of elements in pmatch[]), since it won't write
> to pmatch[] at all.
> 
> Is the following call valid, or is it UB?
> 
>     regmatch_t  pmatch = {
>         .rm_so = string,
>         .rm_eo = string + 42,  // Assume this offset is valid
>     };
> 
>     regexec(preg, string, 0, pmatch, REG_NOSUB | REG_STARTEND);
> 
> How about this?
> 
>     regexec(preg, string, 999, pmatch, REG_NOSUB | REG_STARTEND);
> 
> 
> Current implementations will work, because nmatch is effectively
> ignored.  But is it intended to be this way, or just an implementation
> detail?

Here's a related question:

    regmatch_t  pmatch = {
        .rm_so = string,
        .rm_eo = string + 42,  // Assume this offset is valid
    };
 
    regexec(preg, string, 0, pmatch, REG_STARTEND);

Should regexec(3) write to the 1st element in pmatch[] because it knows
it exists (otherwise the call would be UB because it needs to read it)?
Or is passing 0 in nmatch effectively another way of performing
REG_NOSUB behavior without actually using the flag?

> 
> Thanks!
> 
> Alex
> 

-- 
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5