Hi наб,
On 4/20/23 21:30, наб wrote:
> On Thu, Apr 20, 2023 at 07:29:27PM +0200, Alejandro Colomar wrote:
>> On 4/20/23 17:35, наб wrote:
>>> --- a/man3/regex.3
>>> +++ b/man3/regex.3
>>> @@ -131,23 +131,30 @@ .SS Matching
>>> above).
>>> .TP
>>> .B REG_STARTEND
>>> -Use
>>> -.I pmatch[0]
>>> -on the input string, starting at byte
>>> -.I pmatch[0].rm_so
>>> -and ending before byte
>>> -.IR pmatch[0].rm_eo .
>>> +Match
>>> +.RI [ string " + " pmatch[0].rm_so ", " string " + " pmatch[0].rm_eo )
>>> +instead of
>>> +.RI [ string ", " string " + \fBstrlen\fP(" string )).
>>> This allows matching embedded NUL bytes
>>> and avoids a
>>> .BR strlen (3)
>>> -on large strings.
>>> -It does not use
>>> +on known-length strings.
>>> +.I pmatch
>>> +must point to a valid readable object.
>> I think this is redundant, since we showed that [0] is accessed by
>> the function.
> Yeah.
>
>>> +If any matches are returned
>>> +.RB ( REG_NOSUB
>>> +wasn't passed to
>>> +.BR regcomp (),
>>> +the match succeeded, and
>>> .I nmatch
>>> -on input, and does not change
>>> -.B REG_NOTBOL
>>> -or
>>> -.B REG_NEWLINE
>>> -processing.
>>> +> 0), they overwrite
>> And of course, nmatch must be at least 1, since otherwise, [0] was
>> not valid, and the whole call would have been UB; right? So that
>> third condition must be true to not invoke UB, so we can omit it too,
>> I think.
> What? idk where you got this from.
> Per 0d120a3c76b4446b194a54387ce0e7a84b208bfd:
> In the regexec() signature
> regmatch_t pmatch[restrict .nmatch],
> is a simplification. It's actually
> regmatch_t pmatch[restrict
> ((.preg->flags & REG_NOSUB) ? 0 : .nmatch) ?:
> !!(.eflags & REG_STARTEND)],
That is a model that was useful in a commit message to describe more
or less what happens. It doesn't need to perfectly describe reality.
Since REG_STARTEND is not in POSIX, we can't read what POSIX says,
so it's all up to how much implementations want to guarantee. I
don't think glibc would like to allow specifying .nmatch as 0 while
the function accesses [0]. The fact that the current implementation
doesn't open Hell's doors to nasal demons doesn't mean it can't do
so in the future. I conceive that _FORTIFY_SOURCE could reasonably
check that pmatch[] has at least .nmemb elements, and I don't want
to preclude that in the documentation.
Cheers,
Alex
>
> If REG_STARTEND, pmatch must point to a valid readable object.
> (Naturally, if you pass in uninitialised memory or a null pointer,
> then you get UB.)
> nmatch is not consulted and has no bearing on this.
>
> Best,
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
