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.
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.
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.
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/
@hexcoder- reported in https://github.com/davidgiven/ack/issues/57
that our getpw() has bugs.
I don't fix these bugs, because Illumos and Linux manual pages say
that getpw() is obsolete. The function can overflow its buffer, so it
is never safe to use. Our libc did not build getpw().
This malloc.h might get confused with the private malloc.h in our
libc. C programs should #include <stdlib.h> for malloc().
This tgmath.h has no useful content, and never worked because
complex.h is missing.
Touch build.lua (by deleting some whitespace) so the *.h globs see
the deletions.
These functions are in POSIX; hypot() is in C99. Also build cabs()
because it rides with hypot(), but don't declare cabs() in any header
file, because our compiler can't parse C99 "double complex" type.
Touch build.lua so it sees that .c files moved.
This undoes part of bfeb736, and returns to using DBL_MAX_EXP and
DBL_MIN_EXP from float.h.
Add a dependency on math/localmath.h and other local header files so
libc is rebuilt when those headers change.
This restores the correct values of DBL_MAX, DBL_MIN_EXP, and related
constants. This fixes some range checks within libc, causing
atof("-36e90") and atof("1.44e-288") to return the correct values.
directories --- wrangling descr files was too hard. C programs can be built
for cpm, pc86, linux386, linux68k!
--HG--
branch : dtrg-buildsystem
rename : util/ack/build.mk => util/led/build.mk
rename : util/LLgen/build.mk => util/topgen/build.mk
These files "magically reappeared" after the conversion from CVS to
Mercurial. The old CVS repository deleted these files but did not
record *when* it deleted these files. The conversion resurrected these
files because they have no history of deletion. These files were
probably deleted before year 1995. The CVS repository begins to record
deletions around 1995.
These files may still appear in older revisions of this Mercurial
repository, when they should already be deleted. There is no way to fix
this, because the CVS repository provides no dates of deletion.
See http://sourceforge.net/mailarchive/message.php?msg_id=29823032
Hosts with sizeof(arith) == sizeof(long) == 8 need to set full_mask[1]
through full_mask[8]. Because MAXSIZE == 8, we only had full_mask[0]
through full_mask[7]. This fix declares arith full_mask[MAXSIZE + 1]
and prevents a fatal error: "array full_mask too small for this machine"
how platform libraries are built. The ARCH pm variable has now been
renamed PLATFORM (which is more accurate) and a different ARCH
variable added, which represents the CPU family rather than the
hardware platform.
