Re[2]: SWT fileviewer fixes (PR=java/9253, PR=java/9254)

[John Murga <john at murga dot org>]

Hey

John>> +  // On windows if the filename ends with ":" it is a drive, to retain the
John>> +  // standard java behaviour we have to add "\." to the end.
John>> +  if (total > 0 && buf[total-1] == ':')
John>> +  {

TT> Isn't this only true if the drive name has a single letter?
TT> (I'm guessing...)

What do you mean ? The "\." on the end or the code ?

I'm pretty sure it is correct... I don't understand what you are getting at.

Drive names on windows do only have one letter, but I don't see how the code
would only work for that (?)... You can have multiple letter device names
("LPT1:") but they are not drives (you can't create files or "cd" to them).

I tested this change.

TT> Actually we also care about _JV_NOT_OWNER.
TT> What are the possible failure modes for WaitForMultipleObjects?
TT> Note that _JV_INTERRUPTED means that Thread.interrupt was called.
TT> Not all failures should return this.

The code in Object.wait() only seemed to throw an "Interrupted" exception.
This was a quick and nasty solution at the best of times to get the SWT
thing working... I know it's bad 8-(

TT> The Windows _Jv_CondWait looks to me like it has some potential bugs.
TT> It unlocks the passed-in mutex, which seems strange.  It looks like
TT> there is a race condition here.  Also, what if the mutex is held more
TT> than once (if the intent is to release it for the duration of the wait
TT> then this code won't work properly).

I don't know enough about the code around it to comment 8-(

BTW you may be able to help with my latest problem... Although I am using
Linux for the builds I have also been playing with Cygwin for cross compiling,
it seems that the only serious problem is with libffi, where some of the
".lo" files end up being blank... this makes "libtool" fail, removing the
offending files from the "libffi" Makefile allows the build process to
continue to completion but when you try to compile with the newly built
GCJ you get lots of "undefined reference to `ffixxx..." errors which I'm
assuming are caused by the bad ".lo" files...

Any ideas ?

Cheers
JohnM