In run.c::assign(), assigning to $0 from $F, a field,
where F >= 2, produces an incoherent cell.
The assignment occurs in two steps, first the string value
and then the float. When the string value is assigned to $0,
setsval invalidates the fields. If FS hasn't changed, after
getfval rebuilds the fields, NF = 1 and F >= 2, therefore $F
is definitely uninitialized. The result is a float val of
0.0, producing a boolean false in the pattern expression.
Coercing a string comparison gives the expected result
because the incoherent cell has the correct string
value, which is not empty and evaluates to true.
when using records in BEGIN, we would read
from the field table before we read into it;
this ensures that the fields are an empty
string before we start touching their contents.
the bug happens when we did the fast exit thru "done" label,
where we would not make sure that theres space in the buffer
for the NUL terminator.
instead, avoid the fast exit and always do the final
adjbuf() that makes sure we have space for the NUL terminator.
remove the pointless pb checks, they'r wrong (should'v
been bp >= buf+bufsz) and adjbuf() already makes sure this
can never happen.
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
the maketab helper program was generated in parallel, which
had a dependency to y.tab.h which lead to yacc running
twice in parallel.
this removes the dependency to y.tab.h in the virtual
maketab.$objtype target to prevent this race condition.
the dependency to y.tab.h is resolved in the main mk at the
$cputype.maketab target which serializes with the other
targets.
Fix inconsistencies between programs and their usage
messages, correct instances where information seems
to be missing or lost. This includes missing arguments,
making usage consistent with manuals, and so on.
don't use rand() and scale it to 0..1, instead call
native frand() which produces uniform random number.
instead of seeding the rng with time(0), use truerand().
problem is NaN() produces a SNaN, not a QNaN... and on the 387,
storing 80 bit SNaN in register to a 64-bit memory destination
traps.
SNaN/QNaN encoding is machine specific. mips has the qiet/signaling
bit inverted.
disabling fp exception in main() now, but that sucks.
i think the best solution would be to not even call strtod() in
is_number() but just write a regex or a little state machine that
will only accept numbers without nan and ±inf.
that might even make it faster and is more robust than relying on
the os's strtod() details.
