[XNU792.1.5] udp_lock x86 bug?
site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Is there not a bug in udp_lock when it comes to x86 architecture: int udp_lock(so, refcount, debug) struct socket *so; int refcount, debug; { int lr_saved; #ifdef __ppc__ if (debug == 0) { __asm__ volatile("mflr %0" : "=r" (lr_saved)); } else lr_saved = debug; #endif if (refcount) so->so_usecount++; so->reserved3= lr_saved; return (0); } There's no warning in gcc when building on a x86? _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... if (so->so_pcb) { lck_mtx_assert(((struct inpcb *)so->so_pcb)->inpcb_mtx, LCK_MTX_ASSERT_NOTOWNED); lck_mtx_lock(((struct inpcb *)so->so_pcb)->inpcb_mtx); } else { panic("udp_lock: so=%x NO PCB! lr=%x\n", so, lr_saved); lck_mtx_assert(so->so_proto->pr_domain->dom_mtx, LCK_MTX_ASSERT_NOTOWNED); lck_mtx_lock(so->so_proto->pr_domain->dom_mtx); } lr_saved is not initialized as far as I can see if __ppc__ is not defined. This email sent to site_archiver@lists.apple.com
participants (1)
-
Stephane Sudre