This is the mail archive of the
mailing list for the Java project.
Re: Patch for Preview: jcf-io.c and Win32 case-insensitive filename handling
- From: "Ranjit Mathew" <rmathew4lists at hotmail dot com>
- To: <gnustuff at thisiscool dot com>,<java-patches at gcc dot gnu dot org>
- Date: Wed, 12 Mar 2003 17:53:12 +0530
- Subject: Re: Patch for Preview: jcf-io.c and Win32 case-insensitive filename handling
- References: <WS054X5Z09XT72ZVEA43LB0UPIEV.3e6e0c93@p733>
- Reply-to: "Ranjit Mathew" <rmathew at hotmail dot com>
> >> This proposed patch aims to resolve gcj compilation glitches due
> >> to the Win32 case-insensitive filesystem. For my native MingW
> >BTW, does it fix the following test case?
> Yes, it does.
By God it does! Thank you for finding this out and fixing it!!
However, I do have some general comments about this patch for
I might be wrong, but AFAIK, the proper way to do this is to define
it as a host file system macro
(http://gcc.gnu.org/onlinedocs/gccint/Filesystem.html) that gets
defined for MinGW by "gcc/config/i386/xm-mingw32.h" in the manner
you indicate and "jcf.h" (or perhaps GCC's system.h) could then
have something like:
#define OPEN_EXACT_CASE open
(This macro could perhaps be of use to other GCC front-ends
and that's why the dropped "JCF_".)
AFAICT, Cygwin will also have to define this, but in a different
way from MinGW because it has a strict_case on/off runtime
setting. (What about MacOS X, where UFS seems to care about
case but HFS+ does not? See
The code looks a bit big to fit in as a macro in a host
header, but then, I don't know where else to really put
it - "gcc/config/i386/winnt.c" looks strictly for instruction
output and nothing else seems to fit...
Perhaps this should really go in libiberty and specified as an
"extra" object for windows (see "libiberty/config/mh-windows").
There are some minor formatting errors - the front-end is
especially strict about such things. For example, "foo(bar)"
v/s "foo (bar)", etc.
In jcf-win32.c, you should FindClose(hFile) *after* you have
determined that hFile is not an INVALID_HANDLE_VALUE.