It has some sort of bug where this code fails:
void main() {
int a;
a = a | 2;
// a |=1;
}
(The commented line that is)
and crr does use "var |= <number>" in some places (cant
remember now, and we recoded our version to go
"var = var | <number>".
I have reported it to Torlak, but you never know if it
gets fixed,
so could you please revamp those or's in crr too?
Logged In: YES
user_id=135378
These are the lines.
(sf-cvs couldn't create a lockfile, so you didn't get a diff
for cvs)
crr_subraces_i.nss:204: iType |= crr_ParseParamValue(
sType );
crr_subraces_i.nss:250: iType |= CRR_SUBRACE_LIGHT;
crr_subraces_i.nss:254: iType |= CRR_SUBRACE_DARK;
crr_subraces_i.nss:257: iType |= CRR_SUBRACE_STONE;
crr_subraces_i.nss:260: iType |=
CRR_SUBRACE_NOT_STONE;
crr_subraces_i.nss:375: iReturn |=
CRR_SUBRACE_LIGHT_SENSITIVE;
crr_subraces_i.nss:377: iReturn |=
CRR_SUBRACE_LIGHT_SENSITIVE_SET;
Logged In: YES
user_id=135378
I tried to respond to the mail I got, but sf.net bounced it.
Grr.
Here is my reply:
> I am working on a minor update to the CRR subrace system
> again and I wanted to make sure that the |= was the only
> problem you had with Torlack's compiler. My recollection is
> that it does not support multiple instances of the same
include
> file, which Bioware's compiler does and which will occur
in the
> CRR code.
That certainly is the only problem I've encountered. We
always recompile with torlacks, and have seen no other ill
effects.
Also, Torlack says that the windows version of his compiler
doesn't show this behaviour, so it might be a linux &
torlack & ( |= in source) combo only.
However, the code in your case probably wont be much harder
to read or anything, so if you change to 'a = a | 2' then
I'd be happy to not have to rewrite it when we upgrade.