> 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
38 matches
Mail list logo