From 164297a322b5dee6addff9ad4acb224302ab6e7d Mon Sep 17 00:00:00 2001 From: наб Date: Fri, 21 Apr 2023 02:39:47 +0200 Subject: regex.3: Improve REG_STARTEND MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Signed-off-by: Alejandro Colomar --- man3/regex.3 | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/man3/regex.3 b/man3/regex.3 index 47fe661d2..e91504986 100644 --- a/man3/regex.3 +++ b/man3/regex.3 @@ -131,23 +131,26 @@ compilation flag 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 + strlen(string)" ). This allows matching embedded NUL bytes and avoids a .BR strlen (3) -on large strings. -It does not use +on known-length strings. +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 +.I pmatch +as usual, and the match offsets remain relative to +.I string +(not +.IR "string + pmatch[0].rm_so" ). This flag is a BSD extension, not present in POSIX. .SS Match offsets Unless -- cgit v1.2.3