Re: [MinGW-dvlpr] java::io::FileDescriptor::open flags seem wrong

[Mohan E. <gnu...@th...>]

Hi Danny,

>I need some java expertise.
>This is motivated by a recent bug report to GCC.
>
>The usage of CreateFile in natFileDescriptorWin32.cc
>(java::io::FileDescriptor::open) looks wrong to me (based on
>semantics of open in C++),

>I don't know java specs at all. Does this look correct to you?

Thanks for looking into this.

Here are my two-cents worth:

- FileDescriptor.open(), implemented in POSIX via natFileDescriptorPosix.cc
  and in Win32 via natFileDescriptorWin32.cc, is not part of the Java API.
  It is an internal helper method which does whatever the libjava folks
  intended it to do. As such, the first place I always look in such cases
  is the corresponding POSIX file (natFileDescriptorPosix.cc) and, in
  my lazy moments, strive for at-least-as-good-as-POSIX compatibility

- If I'm less lazy and want to go beyond "at-least-as-good-as-POSIX compatibility",
  the next thing I do is peruse the JavaDoc. Since FileDescriptor.open()
  does not exist, the closest specification I could find is:

  http://java.sun.com/j2se/1.4.2/docs/api/java/io/FileOutputStream.html#FileOutputStream(java.io.File)

  which seems to support your theory that trying to open read-only files
  shouldn't work. As for what should happen then an existing file is
  opened for truncation, the spec is unclear.

- The final step is to write a simple test case, run it against Java's
  JDK, and try to determine and compare its behavior in a blackbox manner.
  This is the ultimate litmus test.

I have to rush off now, so I don't have time to write the test. I'll do
that the next chance I get. If you finish your rugby shower in less than
five minutes and don't feel like doing mmap, you can send me pseudocode
for a test case as well as things I should check for. Otherwise, I'll
code one up based on your email.

BTW: I've submitted a massive cleanup patch for 3.4 which doesn't address
this, but does touch natFileDescriptorWin32.cc, so the best thing would
probably be to incorporate any changes into mine if yours doesn't apply
cleanly on top of mine (or before mine):

http://gcc.gnu.org/ml/java-patches/2003-q3/msg00064.html

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/