On Sun, 24 Sep 2000, Matt Dillon wrote:
> :: > 132 /*
> :: > 133 * Look up the address in the table for that Address Family
> :: > 134 */
> :: > 135 if (rnh && (rn = rnh->rnh_matchaddr((caddr_t)dst, rnh)) &&
> :: > 136 ((rn->rn_flags & RNF_ROOT) == 0)) {
> ::
> :: C doesn't guarantee order of execution in if ( bleh && bleh &&
> :: bleh). It may very well evaluate it backwards, or from the inside out if
> :: it wants. No?
> :
> :No. That's not right. It evaluates left to right. rnh is checked
> :for null, then matchaddr is called and then rn->rn_flags is checked.
> :
> :Warner
>
> Yah. C definitely guarentees the order of execution for && and ||. The
> moment a clause fails for an &&, the rest of the expression is skipped.
> The moment a clause succeeds for an ||, the rest of the expression is skipped.
I have had three more panics in the last two hours. I didn't get a crash
dump on the first two (keyboard stuff again), but I got one on the last.
I am omitting a stack trace because it looks the same as the others. I am
still not certain whether it's a hardware problem or a FreeBSD problem.
At any rate, I am about to plunk down a wad of cash (metaphorically
speaking) for some new RAM. If anyone has had any insight into this
problem, please let me know.
Thanks,
Michael
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
