Post by Rich FelkerPost by Rich FelkerPost by Rich FelkerPost by Felix Jandawhen deciding whether to resize the buffer, the terminating null byte
was not taken into account
---
src/stdio/getdelim.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/stdio/getdelim.c b/src/stdio/getdelim.c
index a88c393..3077490 100644
--- a/src/stdio/getdelim.c
+++ b/src/stdio/getdelim.c
@@ -27,7 +27,7 @@ ssize_t getdelim(char **restrict s, size_t *restrict n, int delim, FILE *restric
for (;;) {
z = memchr(f->rpos, delim, f->rend - f->rpos);
k = z ? z - f->rpos + 1 : f->rend - f->rpos;
- if (i+k >= *n) {
+ if (i+k+1 >= *n) {
if (k >= SIZE_MAX/2-i) goto oom;
*n = i+k+2;
if (*n < SIZE_MAX/4) *n *= 2;
--
2.4.9
This patch raised a potential conformance issue, that by a strict
reading of the spec, getdelim is only permitted to realloc if the
"If *lineptr is a null pointer or if the object pointed to by
*lineptr is of insufficient size, an object shall be allocated as
if by malloc() or the object shall be reallocated as if by
realloc(), respectively, ..."
I'm going to change the +1 to +!z and add a comment. The idea is that
the +1 was only needed in order for the result to fit if the delimiter
has not already been found; if the memchr found it, an exact-sized
buffer was being expanded unnecessarily.
I'm replying to this thread and CC'ing in case there are any problems
I'm missing in my new fix.
This fix actually looks insufficient; it doesn't fix the case where
the getc produces EOF rather than a character.
OK, the problem here is actually a lot more fundamental than I
realized. If you read the standard as disallowing realloc unless it's
necessary for the result to fit, then there's a circular dependency
here. You can't realloc without knowing whether the next getc will
succeed, but you can't getc without knowing there'll be at least 2
additional bytes to store the result and the null terminator.
If you could fit one additional byte without allocating, but not two,
there's no way to proceed.
instead of realloc, malloc a new buffer that will be large enough,
attempt the getc, and then either switch to it (freeing the original
buffer) or free it (keeping the original buffer) depending on whether
EOF is returned.
In almost all cases, this logic can be skipped. It's not necessary at
all if the stdio stream is buffered, since we can just unget back.
(Using unget works mechanically for unbuffered streams too, but it
violates the invariant that no interface except ungetc or scanf
families should leave logical FILE position not equal to underlying
open file descriptor's offset). It's also not necessary for additional
growth after the first time, since enlarging is already committed.
Reading the glibc source, it looks like in the event of realloc
failure, the character that should have been read remains in the stdio
buffer for an "unbuffered" file (equivalent to my ungetc method above,
violating the invariant) and the output buffer is not null-terminated.
I was a bit surprised at the latter aspect at first, but it's what
we're doing too, and reviewing the spec it seems correct:
"The characters read, including any delimiter, shall be stored in
the object, and a terminating NUL added when the delimiter or
end-of-file is encountered."
It's not even clear to me that there's *any* contract on the output
buffer contents when an error (ENOMEM or otherwise) happens, but
morally/QoI there's a principle that not losing data is a good thing,
and the least lossy behavior is that, on ENOMEM, the entire output
buffer (up to the size) contains bytes read from the file.
This can be achieved without the above fancy allocation juggling. The
following looks like it should work:
1. Always skip allocating the extra byte for the getc (reverting the
above patch).
2. After the getc, if there's no room to store it in the output
buffer without taking the last spot the null would go in, unget and
continue the loop.
3. If reallocation fails, copy as much as fits from the stdio buffer
into the output buffer before returning. This will always be at
least 1 byte (because 1 byte was being saved for the nul), and thus
will consume any ungetc from 2.
I'll see if I can work out a patch and test this.
Rich