> 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
1003.1g isnt what matters - SuS is.
> that I would need to convince Sun to change the compatibility test
> suite. However, if the 1003.1g draft even ment
On Thu, Oct 19, 2000 at 12:30:52AM +0100, Alan Cox wrote:
> > Assuming that my "compatibility argument" is not considered valid. What
> > I really need is some good ammunition for going back to Sun to ask them
> > to change the JRE spec -- like some significant kernel features or Linux
> > applic
> [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 JV
On Fri, 20 Oct 2000, Matt Peterson wrote:
> cvs-1.10.8/vms/rcmd.c:64:rs = bind(s, (struct sockaddr *)&local_isa,
^^^
> sizeof(local_isa));
> cvs-1.10.8/vms/rcmd.c:79:rs = bind(s, (struct sockaddr *)&local_isa,
^^^
> sizeof(local_isa));
>
> The cvs code does c
Eric Lammerts wrote:
>
> On Fri, 20 Oct 2000, Matt Peterson wrote:
> > 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
> > wh
On Fri, 20 Oct 2000, Matt Peterson wrote:
> 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 EADDRNOTA
[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 say
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 e
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so that systems using dynamic addressing
> may elect to get the different bind() behavior.
>
> Later,
> David S. Miller
> [EMAIL PROTECTED]
If a system uses dynamic addressing, binding to a
On Thu, Oct 19, 2000 at 10:45:02AM -0700, David S. Miller wrote:
> To this I agree, but I cannot change the fact that this assumption
> does exist in applications, so this is why I reverted the change.
Would you accept a patch for an setsockopt to enable it again ?
-Andi
-
To unsubscribe from
Date:Thu, 19 Oct 2000 11:35:12 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
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?
He is arguing that returning a
On Thu, Oct 19, 2000 at 11:35:12AM -0600, Matt Peterson wrote:
> Again, there is not a bug in the JVM's handling of
> java.net.DatagramSocket(). I offered the JVM as an example only because
> it is one application that I know of expects the standardized behavior
> of bind(). The bind() behavior
Andi Kleen wrote:
>
> > The JRE compliance tests have a test which makes sure that for a
> > non-local addresses, bind() returns an error code, specifically
> > -EADDRNOTAVAIL.
>
> Sounds like a bug that should be reported to Sun.
>
Hello? Send a bug to Sun? I don't see any logic here. I h
On Thu, Oct 19, 2000 at 09:35:20AM -0700, David S. Miller wrote:
>Date: Thu, 19 Oct 2000 18:30:22 +0200
>From: Andi Kleen <[EMAIL PROTECTED]>
>
>On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote:
>> I'll say it again, if you have to make changes to apps/servers the
>
"David S. Miller" <[EMAIL PROTECTED]> writes:
>Date: Thu, 19 Oct 2000 09:07:57 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Hence, the JVM fails compatibility on Linux 2.4.
>
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so t
Date: Thu, 19 Oct 2000 18:30:22 +0200
From: Andi Kleen <[EMAIL PROTECTED]>
On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote:
> I'll say it again, if you have to make changes to apps/servers the
> feature does not make any sense. It must operate transparently or
>
In article <[EMAIL PROTECTED]> you wrote:
> Thus spake David S. Miller ([EMAIL PROTECTED]):
>> I'll say it again, if you have to make changes to apps/servers the
>> feature does not make any sense. It must operate transparently or
>> not at all.
> There once was a socket file system which solved
Date:Thu, 19 Oct 2000 18:18:34 +0200
From: Felix von Leitner <[EMAIL PROTECTED]>
There once was a socket file system which solved exactly this
problem in a nice and obvious way. If you wanted to allow user joe
to bind to port 80, you just do "chown joe /socks/80".
I do no
On Thu, Oct 19, 2000 at 09:02:12AM -0700, David S. Miller wrote:
>Date: Thu, 19 Oct 2000 17:56:17 +0200
>From: Andi Kleen <[EMAIL PROTECTED]>
>
>It would be better if there was at least an socket option to
>overwrite the sysctl. What happens when you need both behaviours on
>t
Thus spake David S. Miller ([EMAIL PROTECTED]):
> I'll say it again, if you have to make changes to apps/servers the
> feature does not make any sense. It must operate transparently or
> not at all.
There once was a socket file system which solved exactly this problem in
a nice and obvious way.
Date: Thu, 19 Oct 2000 17:56:17 +0200
From: Andi Kleen <[EMAIL PROTECTED]>
It would be better if there was at least an socket option to
overwrite the sysctl. What happens when you need both behaviours on
the same box in different applications ? (e.g. a dynamic IP box
running ja
On Thu, Oct 19, 2000 at 08:17:28AM -0700, David S. Miller wrote:
>Date: Thu, 19 Oct 2000 09:23:26 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Have you thought about an SOL_SOCKET level socket option? It might
>be more intuitive for programmers than an ioctl and could be
>
"David S. Miller" wrote:
>
>Date: Thu, 19 Oct 2000 09:23:26 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Have you thought about an SOL_SOCKET level socket option? It might
>be more intuitive for programmers than an ioctl and could be
>documented with sockets where it wi
Date: Thu, 19 Oct 2000 09:23:26 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Have you thought about an SOL_SOCKET level socket option? It might
be more intuitive for programmers than an ioctl and could be
documented with sockets where it will be used.
Where did I say "ioctl"?
T
"David S. Miller" wrote:
>
>Date: Thu, 19 Oct 2000 09:07:57 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Hence, the JVM fails compatibility on Linux 2.4.
>
> Due ot this and other reasons I'm restoring the 2.2.x behavior by
> default, but adding a sysctl so that systems using d
Date: Thu, 19 Oct 2000 09:07:57 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Hence, the JVM fails compatibility on Linux 2.4.
Due ot this and other reasons I'm restoring the 2.2.x behavior by
default, but adding a sysctl so that systems using dynamic addressing
may elect to get the dif
"David S. Miller" wrote:
>
>Date:Wed, 18 Oct 2000 17:20:22 -0600
>From: Matt Peterson <[EMAIL PROTECTED]>
>
>Assuming that my "compatibility argument" is not considered valid.
>What I really need is some good ammunition for going back to Sun to
>ask them to change the
Horst von Brand wrote:
> > > How about first finding out why their buggy JRE detects whether an
> > > address is local by trying to bind() to it :-)
>
> > I don't know why the JRE does it, but I've seen that sort of thing used
> > to decide whether to try X shared memory.
>
> Could you explain t
[EMAIL PROTECTED] writes:
> Hello!
>
> > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> > address. The correct behavior should be a return code of -1 with errno
> > set to EADDRNOTAVAIL.
>
> You can bind to any address, it is your right. You will not able
> to recei
Followup to: <[EMAIL PROTECTED]>
By author:"David S. Miller" <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> How about first finding out why their buggy JRE detects whether an
> address is local by trying to bind() to it :-)
>
> Really, when an application feeds a specific address in
Jamie Lokier <[EMAIL PROTECTED]> said:
> David S. Miller wrote:
> > How about first finding out why their buggy JRE detects whether an
> > address is local by trying to bind() to it :-)
> I don't know why the JRE does it, but I've seen that sort of thing used
> to decide whether to try X shared m
> The XNS specification seems loose enough to allow the Linux
> behaviour. I don't
> think we should however adopt it as default behaviour. Programs
> that dont care
> about addresses use INADDR_ANY.
>
> Alan
I worry that an application may use ability to bind to determine whether an
ad
David S. Miller wrote:
> How about first finding out why their buggy JRE detects whether an
> address is local by trying to bind() to it :-)
I don't know why the JRE does it, but I've seen that sort of thing used
to decide whether to try X shared memory.
-- Jamie
-
To unsubscribe from this list:
> Assuming that my "compatibility argument" is not considered valid. What
> I really need is some good ammunition for going back to Sun to ask them
> to change the JRE spec -- like some significant kernel features or Linux
> applications that relies on this new bind() behavior.
The XNS specifica
Date:Wed, 18 Oct 2000 17:20:22 -0600
From: Matt Peterson <[EMAIL PROTECTED]>
Assuming that my "compatibility argument" is not considered valid.
What I really need is some good ammunition for going back to Sun to
ask them to change the JRE spec -- like some significant kerne
On Wed, Oct 18, 2000 at 05:20:22PM -0600, Matt Peterson wrote:
> Your argument for supporting dynamic interfaces is valid, I really like
> the idea of being able to bind to an interface that is not up yet. I can
> definitely see where this would be helpful -- too bad is is not part of
> the spec.
[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> > address. The correct behavior should be a return code of -1 with errno
> > set to EADDRNOTAVAIL.
>
> You can bind to any address, it is your right. You will not able
> to rece
Hello!
> Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
> address. The correct behavior should be a return code of -1 with errno
> set to EADDRNOTAVAIL.
You can bind to any address, it is your right. You will not able
to receive on or to send from such socket until add
Using linux-2.4.0-test9, bind() incorrectly allows a bind to a non-local
address. The correct behavior should be a return code of -1 with errno
set to EADDRNOTAVAIL. (Simple snippet to reproduce/debug the problem is
available on request)
There appears to be significant differences between the
n
39 matches
Mail list logo
