Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!zehntel!dual!mats
From: mats@dual.UUCP (Mats Wichmann)
Newsgroups: net.sources
Subject: Another corewar problem
Message-ID: <643@dual.UUCP>
Date: Tue, 3-Jul-84 16:03:16 EDT
Article-I.D.: dual.643
Posted: Tue Jul  3 16:03:16 1984
Date-Received: Wed, 4-Jul-84 03:51:06 EDT
Distribution: net
Organization: Dual Systems, Berkeley, CA
Lines: 28

Another problem with the Corewar program beyond the one already fixed
in this newsgroup is that differences in the rand() function are not
accounted for. BSD (4.1 & 4.2) returns a number in the range
0 to 2^31 - 1; System V (and presumably other AT&T releases) return
a number in the range 0 to 2^15 -1. In the routine load(), a random
number is generated for the load address of the second program in a loop 
which continues if the number is not far enough from the address the first
program was loaded at. In generating the number, the return value from
rand() is right-shifted by 12, which will make it too small (on USG
systems with the smaller return range) to ever become a legal address -
thus an endless loop with no exit....

Fix is to decrease the right-shift amount for USG Systems (such as our
System V). A simple change follows, including Berry's original comment.

Note: also remember that for System III/V UNIX, index() is called strchr().

	Mats

======= corewar.c =============
162c162
< 	r = (rand() >> 12) % MEMSIZE;	/* 4.1 rand() sucks */
---
> 	r = (rand() >> 3) % MEMSIZE;	/* 4.1 rand() sucks */
169c169
< 			r = (rand() >> 12) % MEMSIZE;
---
> 			r = (rand() >> 3) % MEMSIZE;