| Age | Commit message (Collapse) | Author |
|---|
|
echo 'a' | awk 'BEGIN { getline l; getline l; print (s=substr(l,1,10)) " len=" length(s) }'
https://github.com/onetrueawk/awk/commit/1debe1993fc852545a9215621d884be27f08a223
|
|
awk 'BEGIN { while(++i <= 100000) { mem = "ps | grep awk"; printf("%d", 1+2, 3+4, 5+6, 7+8, 9+0) > "/dev/null"; if(i % 10000 == 0) system(mem) }}'
https://github.com/onetrueawk/awk/commit/821c502359855d0c43be8e9b08f037ecb543d310
|
|
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.
|
|
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
|
|
|
|
|
|
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().
|
|
|
|
|
|
code divisor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
be more carefull. have to preserve DONTFREE flag!
|
|
the freesymtab() call frees the y argument. temporarily mark it
not to be freed.
|
|
|
|
|
