root@libove.UUCP (The Super User) (02/02/88)
I attempted to build the recently posted "conquer" game on SCO Xenix
(system 2.2.1, development system 2.1.4) and in magic.c on lines 73
and 74 (and a few others) I get an error "case value 0 already used".
I looked at a preprocessed version of magic.c (cc -E) and it showed
quite clearly that the cases were all distinct. I put in a #ifdef M_XENIX
to use a "long int newpower" rather than "int newpower" because SCO
Xenix 2.2.1 /286 is a 16-bit system, and the distribution value of
MAXPOWER (in statement "newpower=1<<rand()%MAXPOWER") is 21... so there
would be some values that could never occur, but that didn't affect
anything when I tried compiling again.
Has anyone else hit this? Does it describe a bug I haven't heard of yet
in the SCO compiler 2.1.4? Has someone got a workaround?
Thanks!
-Jay Libove {pitt | bellcore}!darth!libove!libove *or* jl42@andrew.cmu.edufortin@zap.UUCP (Denis Fortin) (02/23/88)
In article <5@libove.UUCP> root@libove.UUCP (The Super User) writes: > >I attempted to build the recently posted "conquer" game on SCO Xenix >(system 2.2.1, development system 2.1.4) and in magic.c on lines 73 >and 74 (and a few others) I get an error "case value 0 already used". > >I looked at a preprocessed version of magic.c (cc -E) and it showed >quite clearly that the cases were all distinct. I put in a #ifdef M_XENIX >to use a "long int newpower" rather than "int newpower" because SCO >Xenix 2.2.1 /286 is a 16-bit system, and the distribution value of >MAXPOWER (in statement "newpower=1<<rand()%MAXPOWER") is 21... so there >would be some values that could never occur, but that didn't affect >anything when I tried compiling again. > >Has anyone else hit this? Does it describe a bug I haven't heard of yet >in the SCO compiler 2.1.4? Has someone got a workaround? There are actually *MANY* problems in getting conquer to run on a machine that has 16-bit integers. For instance, the "powers" range in value from 2**0 to 2**20, but they are often treated as normal int values by the code. money is also a problem. Even though most monetary values are kept as "long", many computations involve normal int constants, which provokes overflows and much *&@@^%$... Furthermore, many printf's have %d where %ld would be required. Anyway, I've toyed with it a bit to get it to run on my Microport SysV/AT, and now it's almost working... If it ends up being relatively stable in the next few weeks, I'll try to prepare a bunch of patches that should allow 80286 people to use it. (Sigh, I want a MicroVAX!) -- Denis Fortin | fortin@zap.UUCP CAE Electronics Ltd | philabs!micomvax!zap!fortin The opinions expressed above are my own | fortin%zap.uucp@uunet.uu.net