Can I say two word about the file
http://cr.openjdk.java.net/~dxu/8001334/webrev.01/src/windows/native/java/io/io_util_md.c.frames.html
and function
     getLastErrorString(char *buf, size_t len)

Here is the documentation for [FormatMessage]:
http://msdn.microsoft.com/en-gb/library/windows/desktop/ms679351%28v=vs.85%29.aspx
if you are using ASCII version of FormatMessage that is a good idea to have the direct reference to [FormatMessageA], not define.

The second word is about the third world countries: Russia and China.
Windows OS has localized version. The error messages on that systems would contains only [?] in the worst case.

===========================
dwLanguageId [in]
The language identifier for the requested message. This parameter is ignored if dwFlags includes FORMAT_MESSAGE_FROM_STRING. If you pass a specific LANGID in this parameter, FormatMessage will return a message for that LANGID only. If the function cannot find a message for that LANGID, it sets Last-Error to ERROR_RESOURCE_LANG_NOT_FOUND. !!!!------------>If you pass in zero, FormatMessage looks for a message for LANGIDs in the following order:

        Language neutral
        Thread LANGID, based on the thread's locale value
        User default LANGID, based on the user's default locale value
        System default LANGID, based on the system default locale value
        US English <-------------!!!!

If FormatMessage does not locate a message for any of the preceding LANGIDs, it returns any language message string that is present. If that fails, it returns ERROR_RESOURCE_LANG_NOT_FOUND.
===========================


On 07.03.2013 16:40, Alan Bateman wrote:
On 05/03/2013 18:39, Dan Xu wrote:
Hi All,

Thanks for your good suggestions. I have updated this fix and put the new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. Please help review it. Thanks!

-Dan

I've looked at the latest webrev and it looks quite good. There are several other things that should be done, like the O_CLOEXEC topic that we discussed here, but they can be done later. The main thing is that we've removed the dependency on the JVM_* functions and so finally being the interruptible I/O story to to end.

For naming then I probably should chosen something other than handle* for the *nix code but I guess what you have is okay.

A few comments on the *nix handleOpen:

- it doesn't look like "flag" is needed as you can pass oflag to open64.

- it looks like close could set errno. At least for the EISDIR case you probably should set this after the close.

- I assume fstat64 should use RESTARTABLE.

A small comment on handleRead/handleWrite is that the return from read/write is normally ssize_t.

Something for another day but we would re-examine handleAppend as the file should be open for O_APPEND already.

Minor nit in handleAvailable is that the last if-then-else is missing braces around the return 0.

Minor nit in the RESTARTABLE macro (io_util_md.c), probably should use 4-space indent.

That's all I have.

-Alan.




Reply via email to