On 4/20/23 17:35, наб wrote:
> Explicitly spell out the ranges involved. The original wording always
> confused me, but it's actually very sane.
>
> Remove "this doesn't change R_NOTBOL & R_NEWLINE" ‒ so does it change
> R_NOTEOL? No. That's weird and confusing.
>
> String largeness doesn't matter, known-lengthness does.
>
> Explicitly spell out the influence on returned matches
> (relative to string, not start of range).
>
> Signed-off-by: Ahelenia Ziemiańska <nabijaczleweli@xxxxxxxxxxxxxxxxxx>
> ---
> man3/regex.3 | 33 ++++++++++++++++++++-------------
> 1 file changed, 20 insertions(+), 13 deletions(-)
>
> diff --git a/man3/regex.3 b/man3/regex.3
> index c5185549b..1ce0a3b7e 100644
> --- 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.
> +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.
> +.I pmatch
> +as usual, and the
> +.B Match offsets
> +remain relative to
> +.IR string
> +(not
> +.IR string " + " pmatch[0].rm_so ).
> This flag is a BSD extension, not present in POSIX.
> .SS Match offsets
> Unless
--
<http://www.alejandro-colomar.es/>
GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
