Repository navigation
pcre2grep: track the file position in PCRE2_SIZE, not int - #1020
Conversation
There was a problem hiding this comment.
This can't be right. You're still casting to int: (int)start but now printing as llu.
The correct way to print a size_t is using %zu - we have the macro SIZ_FORM for that.
|
Now you've expanded I think you're right that the correct unit is size_t. The fact that fseek/ftell work in longs shouldn't drive anything. I also dislike the fact the linelength is unsigned and endlinelength is signed. That's a quite unfortunate implicit conversion for |
|
I've revised my opinion! Clearly If you don't feel brave enough to tackle the |
|
Thanks for the review. Switched to int64_t and adjusted the printf format, pushed. The off_t migration sounds like its own project, happy to leave that for later. |
|
Thanks! The first |
|
See also #1024 for the future work. |
|
Good catch, fixed that one too and pushed. Both output paths now use long long consistently. |

Problem
pcre2greptracks the input file position in anint(src/pcre2grep.c:int filepos = 0;) and accumulates the per-line advance into it with narrowing casts:On files larger than 2GiB the counter overflows: the
-obyte-offset output prints wrapped (negative) offsets via%d, and the restart path computesfseek(handle, stream_start + (long int)filepos, SEEK_SET)from the wrapped value. This follows the same multiline-advance code that #956 recently touched.Fix
Track
fileposasPCRE2_SIZE, drop the narrowing casts, and print the offsets as unsigned long long. No behavioral change below 2GiB.Verification
Full ctest suite passes; the arithmetic change is mechanical (no test fixture can practically carry a >2GiB file).