ef2fdb6fdd
Before the "native" awk work, a call to the fflush function resulted in one or more calls to the APE fflush(2). Calling fflush on a stream open for reading has different behavior based on the environment: within APE, it's a no-op¹; on OpenBSD, it's an error²; in musl, it depends on whether or not the underlying file descriptor is seekable³; etc. I'm sure glibc is subtly different. Now that awk uses libbio, things are different: calling Bflush(2) on a file open for reading simply discards any data in the buffer. This explains why we're seeing truncated input. When awk attempts to read in the next record, there's nothing in the buffer and no more data to read so it gets EOF and exits normally. Note that this behavior is not documented in bio(2). It was added in the second edition but I haven't figured out why or what depends on it. The simple fix is to have awk only call Bflush on files that were opened for writing. You could argue that this is the only correct behavior according to the awk(1) manual and it is, in fact, how GNU awk behaves⁴. 1. /sys/src/ape/lib/ap/stdio/fflush.c 2. https://cvsweb.openbsd.org/src/lib/libc/stdio/fflush.c?rev=1.9 3. https://git.musl-libc.org/cgit/musl/tree/src/stdio/fflush.c 4. https://git.savannah.gnu.org/cgit/gawk.git/tree/io.c#n1492 |
||
|---|---|---|
| .. | ||
| doc | ||
| games/lib | ||
| include | ||
| lib | ||
| man | ||
| src | ||