This resulted in the NUL terminator being written to the end of the
buffer which was not the same as the end of the string. That in
turn caused garbage bytes from malloc() to be processed. Also
change the NUL termination to be less error prone by writing the
NUL immediately after the last byte copied.
Reproducible with the following under valgrind:
echo '#!/usr/bin/awk' | awk \
'/^#! ?\/.*\/[a-z]{0,2}awk/ {sub(/^#! ?\/.*\/[a-z]{0,2}awk/,"#! awk"); print}'
* Cast to uschar when storing a char in an int that will be used as an index.
Fixes a heap underflow when the input char has the high bit set and
FS is a regex.
* Add regress test for underflow when RS is a regex and input is 8-bit.
POSIX specifies a dprintf function that operates on an fd instead of
a stdio stream. Using upper case for macros is more idiomatic too.
We no longer need to use an extra set of parentheses for debugging
printf statements.
* sprinkle const, static
* account for lineno in unput
* Add an EMPTY string that is used when a non-const empty string is needed.
* make inputFS static and dynamically allocated
* Simplify and in the process avoid -Wwritable-strings
* make fs const to avoid -Wwritable-strings
- sprinkle const
- add a macro (setptr) that cheats const to temporarily NUL terminate strings
remove casts from allocations
- use strdup instead of strlen+strcpy
- use x = malloc(sizeof(*x)) instead of x = malloc(sizeof(type of *x)))
- add -Wcast-qual (and casts through unitptr_t in the two macros we
cheat (xfree, setptr)).
When matching a caret, the expression `f->gototab[s][c] = f->curstat;` in
cgoto() will index the 2D-array gototab with [s][261]. However, gototab
is declared as being of size [NSTATES][NCHARS], so [32][259]. Therefore,
this assignment will write to the state for character 0x1.
I'm not sure how to create a regression test for this, but increasing the
array size to HAT+1 values fixes the error and the tests still pass.
I found this issue while running awk on a CHERI system with sub-object
protection enabled. On x86, this can be reproduced by compiling awk
with -fsanitize=undefined.
Support POSIX-specified C-style escape sequences "\a" (alarm)
and "\v" (vertical tab) in command line arguments and regular
expressions, further to the support for them in strings added on
Apr 9, 1989. These now no longer match as literal "a" and "v"
characters (as they don't on gawk and mawk).
IOW, lex.c already supported these (lines 390-391 as of 4e343460);
the support needed to be added to b.c and tran.c.
Relevant POSIX reference:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/awk.html#tag_20_06_13_04
Also remove a redundant semicolon.
Also had to rebase on upstream pull.
git-svn-id: svn+ssh://svn.freebsd.org/base/head@301289 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
The lack of POSIX interval expressions[*] (a.k.a. bounds, a.k.a.
repetition expressions) in regular expressions is listed under BUGS
in 'awk.1'. Apple's version of onetrueawk has supported these since
at least 2009, judging by the date stamp on their src/b.c in:
https://opensource.apple.com/tarballs/awk/awk-24.tar.gz
A bug report prompted NetBSD to swiftly integrate this code into
their awk. This commit is based on that NetBSD diff.
http://gnats.netbsd.org/53885f3e4c4ca1d
b.c:
- Backport POSIX-standard interval expressions support in regular
expressions via NetBSD from Apple awk-24 (20070501).
main.c:
- Bump version ID.
FIXES:
- Add note and credit for this feature.
awk.1: section BUGS:
- Remove line saying interval expressions are not supported.
_________
[*] http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04_06
Because NCHARS is (256+3) cc->cc_func(i) was called with 256, 257
and 258 as argument leading to possible undefined behaviour (at
least on NetBSD with non-C locale (e.g. `en_US.UTF-8') this led to
only honoring one `[:...:]' character class in bracket expressions).
Fix#11
