This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: java.io.FileDescriptor enhancement
- From: Tom Tromey <tromey at redhat dot com>
- To: Michael Koch <konqueror at gmx dot de>
- Cc: java-patches at gcc dot gnu dot org
- Date: 01 Apr 2003 01:15:07 -0700
- Subject: Re: java.io.FileDescriptor enhancement
- References: <200303302015.38877.konqueror@gmx.de><87k7eeyjqq.fsf@fleche.redhat.com><200304011010.18547.konqueror@gmx.de>
- Reply-to: tromey at redhat dot com
>>>>> "Michael" == Michael Koch <konqueror at gmx dot de> writes:
Michael> I wondered about the usage of 'long' for the native fd in
Michael> classpath. Why not int ? Isnt int big enough for 64 bit
Michael> archs ? Or is it just to be on the safe side ?
int is only 32 bits. Classpath is probably taking the approach of
assuming that we don't know anything about the underlying fd -- it
might be a pointer on a 64-bit machine. This is a pretty reasonable
thing to do. Maybe there's some embedded OS that does this. Or maybe
you want to use stdio for your FileDescriptor implementation. Or
maybe there's a 64 bit Windows (I assume there is but I really don't
know).
Michael> I want to avoid using the native fd directly in java.nio because it
Michael> cannot be shared. And the advantage is that it handles close()
Michael> correctly when called more then once. With long (int) as fd type we
Michael> will have problems.
I'm confused. I thought your patch exposed the underlying int to
java.nio. But this quoted paragraph seems to indicate that it isn't
what you want.
Tom