em libmon vanished decades ago (or never existed), and also ass appears to have
a different idea of what the em opcodes are to everything else and gets
confused.
*Important:* Do `make clean` to work around a problem and prevent
infinite rebuilds, https://github.com/davidgiven/ack/issues/68
I edit tokens.g in util/LLgen/src, so I regenerate tokens.c. The
regeneration script bootstrap.sh can't find LLgen, but I can run the
same command by typing the path to llgen.
aprintf() returns a const char *; the assignment to char * caused both
clang and gcc to warn of the dropped const.
Commit 893471a introduced a tiny memory leak, because GetFile()
stopped freeing buf. The const return type of aprintf() suggests that
the buffer must not be freed.
Now use Malloc() to allocate the buffer and free() to free it. This
also checks if we are out of memory, because Malloc() does the check
and aprintf() currently doesn't.
Edit build.lua for programs losing their private assert.h, so they
depend on a list of .h files excluding assert.h.
Remove modules/src/assert; it would be a dependency of cpp.ansi but we
didn't build it, so cpp.ansi uses the libc assert.
I hope that libc <assert.h> can better report failed assertions. Some
old "assert.h" files didn't report the expression. Some reported a
literal "x", because traditional C expanded the macro parameter x in
"x", but ANSI C89 doesn't expand macro parameters in string literals.
@dram reported a build failure in FreeBSD at
https://github.com/davidgiven/ack/issues/1#issuecomment-273668299
Linux manual for getopt(3) says:
> If the first character of optstring is '-', then each nonoption
> argv-element is handled as if it were the argument of an option with
> character code 1....
>
> The use of '+' and '-' in optstring is a GNU extension.
GNU/Linux and OpenBSD handle '-' in this special way, but FreeBSD
seems not to. If '-' is not special, then em_ego can't find its input
file, so the build must fail. This commit stops using '-' in both
em_b and em_ego, but doesn't change mcg.
Also fix em_ego -O3 to not act like -O4.
This prevents an overflow reported by @hexcoder- in
https://github.com/davidgiven/ack/issues/56
lang/cem/cpp.ansi/LLlex.c used a plain 1 << ... and caused an overflow
on machines where sizeof(int) < sizeof(long). Using 1L << ... would
work for now but might fail later if arith became long long.
C doesn't specify whether negative integers use 2's complement or some
other format. Therefore, (arith) 1 << ... has an undefined value. It
should still work because the value is some integer where the sign bit
is set and all other bits are clear.
(unsigned arith) 1 << ... would also get the sign bit, but casting it
from unsigned back to signed would make the same undefined value.
(arith) -1 << ... would assume 2's complement.
Reported by me in https://github.com/davidgiven/ack/issues/60
This doesn't change DIV. Right now a DIV b does floor division and
a MOD b has the sign of b. This is the same as Lua, Python, Ruby,
Tcl; but is different from other Modula-2 implementations.
Traditional C compilers had long but not unsigned long. I now assume
that everyone can compile unsigned long. Remove macro UNSIGNED_ARITH
and act like it is always defined. The type `unsigned arith` works
because arith is a macro for long.
If feof(fp) or ferror(fp) was set, then our libc returned EOF for all
later reads without trying to read. Our libc now behaves like BSD
(and probably Illumos and musl) by checking only feof(fp). For
difference, glibc doesn't check feof(fp).
I described the difference between our libc and BSD libc in
https://sourceforge.net/p/tack/mailman/message/35430300/
