Path: utzoo!utgpu!water!watmath!watcgl!watmum!rmariani
From: rmariani@watmum.waterloo.edu (Rico Mariani)
Newsgroups: comp.sys.amiga
Subject: Some gotchas in Aztec 3.4
Message-ID: <4242@watcgl.waterloo.edu>
Date: 3 May 88 07:13:55 GMT
Sender: daemon@watcgl.waterloo.edu
Distribution: na
Lines: 62

Well another working day has passed and here are two bugs to watch out for:

1.  The m32 library defines the function abs() as a floating point absolute
value.  This disagrees with the UNIX definition... The UNIX C libraries
define abs as an integer in integer out function.

2.  This one is complicated.  Consider a big program compiled with the
small code model (this is OK according to the manuals).  Say it's
way bigger than 64k, like about 200k or so.  Now suppose that there
are 2 modules that contain code like this:

map.c
-----

int map() { ... }

int mmap(f)
int (*f)();
{
	...
	if ( f == map)
		printf("Yes\n");
	else
		printf("No\n");
	...
}

eval.c	(code is far away (>64k) from the other module)
------

int map();

eval()
{
	...
	mmap(map);
	...
}

You would expect that when eval calls mmap that the output would be "Yes"
right?  Well you'd be wrong.
In the small memory model, a reference to 'map' which is not within range
(like the one in eval) turns into a reference to the function jump table.
This table has lots of entries like.

(_map):		jmp _map

The table is kept in the data segment so that all functions can see it.
This is normally great, if I try to call map it instead calls the jump
table in the data segment and --poof-- we're in the map function just fine.
However in the above case the map symbol refers to the jump table
in file eval.c and it refers to the actual code in the file map.c so
when the comparison happens it fails!

-------

By the way I wouldn't have found this bug in a million years if I hadn't
run out and bought SDB.  SDB is the greatest...  Good work Jim!

	-Rico

P.S.  I offered to be a Beta tester, I even wrote a letter to Manx...  :-)