This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Thu Apr 25 12:49:38 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8HKeDi05436 for ; Tue, 17 Sep 2002 22:40:15 +0200 Received: (qmail 32402 invoked from network); 17 Sep 2002 20:24:01 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 17 Sep 2002 20:24:01 -0000 Received: (qmail 24545 invoked by uid 1000); 17 Sep 2002 19:46:32 -0000 Received: (maildatabase); juh Received: (qmail 1223 invoked by alias); 20 Oct 2000 17:50:47 -0000 Received: (qmail 1160 invoked from network); 20 Oct 2000 17:48:01 -0000 Received: from vger.kernel.org (199.183.24.194) by spaans.ds9a.nl with SMTP; 20 Oct 2000 17:48:01 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Fri, 20 Oct 2000 14:03:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Fri, 20 Oct 2000 14:03:47 -0400 Received: from mail.calderasystems.com ([216.250.130.2]:6916 "EHLO mail.calderasystems.com") by vger.kernel.org with ESMTP id ; Fri, 20 Oct 2000 14:03:31 -0400 Received: (qmail 12393 invoked by uid 0); 20 Oct 2000 17:46:48 -0000 Received: from mpeterson@calderasystems.com by mail.calderasystems.com with scan4virus-0.50 (uvscan: v4.0.70/v4077. . Clean. Processed in 0.216331 secs); 20/10/2000 11:46:48 Received: from ns.calderalabs.com (root@216.250.131.1) by mail.calderasystems.com with SMTP; 20 Oct 2000 17:46:48 -0000 Received: from calderasystems.com (mpeterson@gomboo.calderalabs.com [216.250.131.136]) by ns.calderalabs.com (8.9.3/8.9.3) with ESMTP id LAA02361; Fri, 20 Oct 2000 11:46:48 -0600 Message-Id: <39F084F2.6FEBB75F@calderasystems.com> Date: Fri, 20 Oct 2000 11:46:26 -0600 From: Matt Peterson X-Mailer: Mozilla 4.73C-CCK-MCD Caldera Systems OpenLinux [en] (X11; U; Linux 2.4.0 i686) X-Accept-Language: en Mime-Version: 1.0 To: David Woodhouse Cc: Andi Kleen , linux-kernel@vger.kernel.org Subject: Re: bind() allowed to non-local addresses References: <39EF30D0.DA2995F1@calderasystems.com> <39EE3036.B4168E75@calderasystems.com> <200010182316.QAA20282@pizda.ninka.net> <39EF0E4C.FFAE0525@calderasystems.com> <200010191459.HAA23560@pizda.ninka.net> <39EF11EE.F66109BB@calderasystems.com> <200010191517.IAA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Envelope-To: <"|/opt/mail/bin/ta/listexpand linux-kernel-owner /opt/Majordomo/lists/linux-kernel"> (uid 400) David Woodhouse wrote: > > mpeterson@calderasystems.com said: > > There is NOT a bug in the JVM code that handles java.net.DatagramSock > > et. Don't you find it a little compelling that the nearly identical > > JVM code passes the Java Compatibility test suite on Linux 2.2, > > Solaris, HPUX, SCO, and even Windows? > > If the JVM spec says that it 'MUST' fail when used on a non-local address, > and the POSIX spec for bind does not say that it 'MUST' fail, then yes, > there is a bug in the JVM if it assumes that the two are compatible. Does some one have a copy of the posix 1003.1g draft so this can be verified. This is the kind of ammunition I was talking about earlier that I would need to convince Sun to change the compatibility test suite. However, if the 1003.1g draft even mentions failure with errno set to EADDRNOTAVAIL in a "SHOULD" context, or if EADDRNOTAVAIL is mentioned at all as a error code for non-local bind, then I am afraid (given the widespread acceptance of bind() behavior), Sun will not change the test suite. > The fact that they just happen to behave the same in certain phases of the > moon and on other operating systems is not relevant. Huh? Please give me one example of a sockets implementation (besides Linux 2.4) of where bind() does not fail if an attempt is made to bind do a non-local address. Your telling me that developers who are used to seeing a consistant behavior across OSes will think that the difference in Linux 2.4 is irrelivant? I don't think so. > We may decide that we want to pander to this brokenness, especially given > the widespread nature of the false assumption that bind() will fail when > given a non-local address. But that doesn't make the JVM non-broken. > Are you also suggesting that every other program that expects bind() to fail with EADDRNOTAVAIL are broken too? Just for fun, I greped all sources of software shipped in Caldera's distributions for instances of where a check is made for EADDRNOTAVAIL after a call to bind(). Guess what else besides Java is probably "broken" ... - lpng - bind 8.2 - automount - cvs - dhcpd - KDE - UCL mbone - ncftp - netatalk - nfsd - rexec - pppd - sendmail - xchat ... but the Linux kernel... Nope, it's not broken. Lets email maintainers of all these projects and tell them that they have been mistaken all this time in their understanding how bind() should work and see what kind of a response we get. Matt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/