When matching a regex with ^, it would attempt to access
gototab[NSTATES][NCHARS+2], and therefore access the state for the \002
character instead. This change is required to run awk under CHERI (with
sub-object bounds) and when running with UBSan instrumentation.
This was committed upstream as cbf924342b
Found by: CHERI (with subobject bounds enabled)
Obtained from: CheriBSD
Reviewed By: imp
Differential Revision: https://reviews.freebsd.org/D26509
In this case, a change was made in one-true-awk from *FS to
getsval(fsloc) in a line just after one of the lines that had the 0 ->
NULL change. It works both ways as far as I can tell. It looks like a
bug fix, but I've not tried to track down which ancient version of
one-true-awk it was in (github starts too late for tracking this
down). Before and after the changes the regression suite is passes
100% relative to the un-modified one-true-awk.
The conversion of 0 -> NULL required a rebase at some point, as noted
in r301289 when pfg commited it. In that rebase, three lines remained
that had been removed in a prior version of awk, and one of them had a
0 -> NULL change causing a conflict. The conflict should have been
resolved by removing the three lines, but wasn't. This introduces a
regression into f.split3 test which prior to this commit we were
failing, but a pure onetrueawk wasn't. Remove the offending 3 lines.
Revert r301689 - one-true-awk: Avoid a NULL dereference.
I got this wrong and the coverity report doesn't match the NetBSD change,
which was thought for a different version.
The change wouldn't hurt but let's wait until upstream figures this out.
Note: this backs out a number of changes we've made to awk because
they aren't upstream, but are on the vendor branch. Those will be
reapplied. svn makes it needlessly difficult to know which ones, but
at least r315426, r301289, and maybe r301691, though there may be
others too. None of these are critical, so bisecting through this
point is safe for all but awk regression tests :).
echo | awk 'BEGIN {i=$1; print i}' prints a boatload of stack
garbage. NUL terminate the memory returned from malloc to prevent it.
Obtained from: OpenBSD run.c 1.40
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D12379
gawk allows multiple arguemnts to bit-wiste and, or and xor
functions. Implement an arbitrary number of arguments for these
functions. Also, use NULL in preference to 0 to match rest of file.
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D12361
These are from OpenBSD:
>>> Extend awk with bitwise operations. This is an extension to the awk
>>> spec and documented as such, but comes in handy from time to time.
>>> The prototypes make it compatible with a similar GNU awk extension.
>>>
>>> ok millert@, enthusiasm from deraadt@
Edited to fix cut and paste in error messages, as well as
using tabs instead of spaces after #defines added.
Obtained From: OpenBSD awk.h 1.12, lex.c 1.10, run.c 1.29
Differential Revision: https://reviews.freebsd.org/D12361
Sponsored by: Netflix
$ echo x | awk '/[[:cntrl:]]/'
x
The NUL character in cntrl class truncates the pattern, and an empty
pattern matches anything. The patch skips NUL as a quick fix.
PR: 195792
Submitted by: kdrakehp@zoho.com
Approved by: bwk@cs.princeton.edu (the author)
MFC after: 3 days
Instead of changing the whole course to another POSIX-permitted way
for consistency and uniformity I decide to completely ignore missing
regex fucntionality and focus on fixing bugs in what we have now,
too many small obstacles we have choicing other way, counting ports.
Corresponding libc changes are backed out in r302824.
I'll try to keep the change very minimal to not touch contribed code much.
I'll send it upstream when it will be merged to main branches,
but we need the change right now here.
I got this wrong and the coverity report doesn't match the NetBSD change,
which was thought for a different version.
The change wouldn't hurt but let's wait until upstream figures this out.
While none of them is considered even near to cryptographic
level, random(3) is a better random generator than rand(3).
Use random(3) for awk as is done in other systems.
Thanks to Chenguang Li for discussing this in the lists
and submitting the patch upstream.
PR: 193147
MFC after: 5 weeks
- Make one-true-awk respect locale's collating order in [a-z]
bracket expressions, until a more complete fix (like handing
BREs) is ready.
- Don't require a space between -[fv] and its argument.
