David Woodhouse wrote:
> 
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to