Partial reads in ${ ... } capture

Partial reads in ${ ... } capture

[Bart Schaefer]

I inadvertently removed a zfree() when moving the guts of stuff() into
zstuff(), so patch below is for the resulting potential (though
unlikely) memory leak on a failed or partial read.

However, I did want to raise a question:  Should this instead return a
partly-filled buffer on a short read?  In which case a different patch
must be applied.

That would require using zshcalloc() when allocating the buffer so
that it would be properly NUL-terminated no matter how many bytes (up
to "len") were placed in it.  The ${ ... } substitution would ignore
the return of -1 and instead check whether anything had been placed in
the buffer.

I would not want to change the result of stuff() because I presume
having "fc" execute the content of a short read is not desirable, but
I'm less certain about command substitution.  Thoughts?

diff --git a/Src/input.c b/Src/input.c
index 8d7f44d7c..dd8f2edc7 100644
--- a/Src/input.c
+++ b/Src/input.c
@@ -632,6 +632,7 @@ zstuff(char **out, const char *fn)
     if (len && !(fread(buf, len, 1, in))) {
     zerr("read error on %s", fn);
     fclose(in);
+    zfree(buf, len + 1);
     unqueue_signals();
     return -1;
     }

Re: Partial reads in ${ ... } capture

[Peter Stephenson]

> On 03/10/2023 01:27 Bart Schaefer <schaefer@brasslantern.com> wrote:
> However, I did want to raise a question:  Should this instead return a
> partly-filled buffer on a short read?  In which case a different patch
> must be applied.

Without knowing a concrete example, I would say it would be cleaner to
leave it as it is.

pws