This will cause ACK libc to provide int64_t as long (instead of long
long) on LP64, if we ever get such a platform.
LP64 would have 64-bit long and 64-bit long long, so int64_t might be
either type. For example on amd64, int64_t is long in NetBSD libc,
and long long in OpenBSD libc. Support for long long in ACK remains
incomplete (no printf "%lld"), so it seems better to prefer long where
possible. Also, int64_t being long before long long is more
consistent with int32_t being int before long.
Put suffixes on the values of INT32_MAX, INT64_MAX, and related
constants, so they have the same types as int32_t and int64_t.
Also change UINT32_MAX in <stdint.h> from 4294967295 to 4294967295U.
The U suffix avoids a promotion to long or unsigned long if it would
fit in unsigned int.
Define _EM_LLSIZE but not EM_LLSIZE. The leading underscore is a
convention for such macros. If code always uses _EM_LLSIZE, we will
never need to add EM_LLSIZE. The flag -D_EM_LLSIZE={q} is in
plat/linux386/descr, not lib/descr/fe, so platforms without long long
don't define _EM_LLSIZE.
<stdint.h> doesn't keep the old code for _EM_LSIZE == 8, because I
change it to _EM_LLSIZE == 8. No platform had _EM_LSIZE == 8, and the
old limits like INT64_MAX were wrong.
breaks the dependency between exit/atexit and stdio. Buffers are no longer
flushed on abort() (because it's pretty risky). Move the relevant functions
into sys/core.
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.
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.
