In my code, either h or w was ALWAYS 0, but until now, this never caused a problem - the MOD operation always resulted in 0. Of course, MOD 0 is undefined, so I’m not surprised this leading to the effect I saw. What surprises me is that this didn’t surface earlier, not even in 64 bit within the debugger.
And Norman, the parentheses are for better readability. Also, since the ObjC compiler started giving warnings when you combined && and || without using parens, I default now to it. Doesn’t hurt, right?
Yeah ?
Are you saying this that changed from 32 to 64 bit ?
I almost wish that MOD was defined as [quote]N mod 0 => N[/quote] but …
that does seem surprising
[quote=456120:@Thomas Tempelmann]
And Norman, the parentheses are for better readability. Also, since the ObjC compiler started giving warnings when you combined && and || without using parens, I default now to it. Doesn’t hurt, right?[/quote]
Not at all
Code clarity is, or should be, a high priority for everyone but I know some like to write really terse code
Yes. As this code was in there for years, and either h or w was always 0, so at least in 32 bit builds (which were all iClip versions until now) the “… MOD 0” op always resulted in zero. Otherwise, the clip bins would have shifted sideways, which would have been noticed.
I might be wrong, but at least this issue only surfaced now, when building for 64 bit, where it occurs practically every time (with “x MOD 0” resulting in random large values).
And here is another related one, again showing differences in behavior in 32/64Bit:
<https://xojo.com/issue/55370> - NaN (Division through 0): Different behavior and comparison results in Target32Bit and Target64Bit