This got caught by MALLOC_OPTIONS=S in OpenBSD. The B compiler filled
the buffer while compiling hilo.b. Then realloc moved the buffer and
unmapped the old buffer. The compiler tried to read the old buffer
and segfaulted.
With this change, I built and ran ack on a big-endian PowerPC Linux
machine. I used gcc 4.9.4 to build ack, and I only built the linuxppc
back end.
Before this change, wr_ranlib() corrupted a value by changing it from
0x66 to 0x66000066. This value was too big, so led made a fatal
error, "bad ranlib string offset".
I made a syntax error in some .e file, and em_encode dumped core
because a 64-bit pointer didn't fit in a 32-bit int. Now use stdarg
to pass pointers to error() and fatal().
Stop using the number of errors as the exit status. Many systems use
only the low 8 bits of the exit status, so 256 errors would become 0.
Also change modules/src/print to accept const char *buf
Drop dependency on <ansi.h> in modules+headers; assume that compiler
knows ANSI C89.
Add missing dependency from print to string; #include <ack_string.h>.
Because <print.h> had commented out the declarations of sys_lock() and
sys_unlock(), I now stop building lock.c and unlock.c.
Some of these functions were slightly different from libc:
- This strncpy() didn't pad the buffer with '\0' bytes beyond the end
of the string; libc does the padding. This string.3 manual said
that this strncpy() does "null-padding", but it didn't.
- This strcmp() and strncmp() compared using char (which might be
signed); libc compares using unsigned char.
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 brings in David Given's PowerPC changes, including the addition
of the modern code generator (mcg) for PowerPC.
Resolve minor conflicts in top build.lua and util/led/main.c
This header declares functions in libobject. Our programs never
included object.h, but called functions in libobject without declaring
them. So, our build system never put object.h in the include path;
any #include <object.h> would fail to find the header.
With this commit, a program may #include <object.h> if it has
modules/src/object+lib in its deps.
Declare structs in object.h so we can use them in prototypes without
gcc warning, "'struct whatever' declared inside parameter list".
Remove inclusion of ansi.h from object.h. Programs would need to
depend on modules+headers to get ansi.h in the include path.
This fixes flt_arith2flt() when sizeof(arith) != 4, where arith is
long. When cemcom.ansi sees an expression like d + 1 (where d is some
double), it calls flt_arith2flt() to convert 1 to floating-point. On
machines where sizeof(arith) != 4, the code did n >>= 1 when n should
not have been changed. If n was 1, then n == 0 became true. This
caused the code to convert 1 or -1 to 0.0.
My fix assumes sizeof(arith) >= 8, so I can use n >> 32. Machines
with sizeof(arith) of 5 to 7 would need to do (uarith)n >> 32, where
uarith must be an unsigned integer type of same size as arith.
In startrek.c, the Enterprise can now dock with a starbase. The
compiler no longer translates s1 - 1 to s1 - 0.0 and s1 + 1 to s1 +
0.0, so the game now looks for starbases next to the Enterprise.
It seems that someone wanted to build flt_arith with a compiler that
had long but not unsigned long. This required extra code to
accomplish unsigned right shift, unsigned division, and unsigned
comparison using the signed operations. Now that we use uint32_t, we
can simply use the unsigned operations and remove the ucmp() function.
We have similar code in mach/proto/fp/ and in
lang/cem/libcc.ansi/stdlib/ext_comp.c where we use the unsigned
operations.
Some long variables become uint32_t, and some masks with 0xFFFFFFFF
disappear because uint32_t has only 32 bits.
Update flt_arith.3 to show that mantissa uses uint32_t.
Provide a target to install modules/src/flt_arith/test.c as flt_test
so I can run the tests.
This seems to fix an error when flt_arith converts a literal
double-precision float to IEEE format. For example, 0.5 and 0.75 got
converted to slightly below their correct values.
My host gcc for amd64 has 64-bit long, but flt_arith needs only 32
bits. The code (at least flt_add.c) can make 32-bit overflows. Such
overflows would set the higher bits of a 64-bit long, which might
cause problems later.
I need to use uint32_t and not int32_t because the code still uses
long, and the sign extension from int32_t to long would cause
problems. The mantissa represents a value in [0, 2) that can't be
negative, so unsigned type is better. Also, signed overflow is
undefined behavior in C, so flt_add.c better make overflows with
uint32_t and not int32_t.
This commit doesn't touch lang/cem/libcc.ansi/stdlib/ext_fmt.h which
continues to use unsigned long for its mantissa fields.
the number of types of relocation possible in the object file. (Now,
hopefully, working.)
Also change the object serialiser/deserialiser to never try to read or
write raw structures; it's way safer this way and we don't need the
performance boost any more.
--HG--
branch : default-branch
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
I already did this in abebf1586c06, but I edited the wrong file. Then
in edddc6b7cd17, I deleted that file.
By fixing fit16i(), I can now compile ACK for OpenBSD/amd64.
