Re: [PATCH 3/6] strbuf_getwholeline: use getc_unlocked
On Sun, Apr 05, 2015 at 12:56:14AM -0400, Jeff King wrote:
Show 5 quoted lines
> The big downside is that our input strings are no longer NUL-clean
> (reading "foo\0bar\n" would yield just "foo". I doubt that matters in
> the real world, but it does fail a few of the tests (e.g., t7008 tries
> to read a list of patterns which includes NUL, and we silently truncate
> the pattern rather than read in the NUL and barf).
diff --git a/strbuf.c b/strbuf.c
index f319d8d..5ceebb7 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -445,12 +445,13 @@ int strbuf_getwholeline(struct strbuf *sb, FILE *fp, int term)
strbuf_reset(sb);
if (term == '\n') {
+ long pos = ftell(fp);
strbuf_grow(sb, 256);
if (!fgets(sb->buf, sb->alloc - 1, fp)) {
strbuf_release(sb);
return EOF;
}
- sb->len = strlen(sb->buf);
+ sb->len = ftell(fp) - pos;
if (sb->buf[sb->len - 1] == '\n')
return 0;
}
but much to my surprise it actually runs slower than the strlen version!
It also has a 32-bit overflow issue. There's fgetpos() as an
alternative, but fpos_t is an opaque type, and we might not be able to
do arithmetic on it (for that matter, I am not sure if arithmetic is
strictly guaranteed on ftell() results). POSIX gives us ftello(), which
returns an off_t. That would probably be fine.
The ftello() version seems slower than the strlen, but faster than
ftell(). Puzzling.
-Peff
Jeff King <peff@peff.net>