When a Windows handle was opened from a CRT fd, it needs to be closed
with `close()` instead of `CloseHandle()`.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
_get_osfhandle() may throw if it's used to convert a non-open file
descriptor to a Windows HANDLE. Use the safe uv__get_osfhandle instead.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When a Windows handle was opened from a CRT fd, it needs to be closed
with `close()` instead of `CloseHandle()`.
PR-URL: https://github.com/libuv/libuv/pull/396
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
src/win/util.c: In function 'uv_os_homedir':
src/win/util.c:1189:46: warning: passing argument 3 of 'GetUserProfileDirectoryW' from incompatible pointer type
if (!GetUserProfileDirectoryW(token, path, &bufsize)) {
^
In file included from src/win/util.c:39:0:
C:/buildtools/vendor/mingw64/x86_64-w64-mingw32/include/userenv.h:52:29: note: expected 'LPDWORD' but argument is of type 'size_t *'
USERENVAPI WINBOOL WINAPI GetUserProfileDirectoryW(HANDLE hToken,LPWSTR lpProfileDir,LPDWORD lpcchSize);
^
PR-URL: https://github.com/libuv/libuv/pull/388
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The previous Windows implementation used SHGetKnownFolderPath(),
which is only supported on Vista and up. This commit switches to
GetUserProfileDirectoryW(), which returns the same information,
but is supported back to Windows 2000, and is not deprecated.
PR-URL: https://github.com/libuv/libuv/pull/375
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
For posterity, these are the rules for access on Windows (taken from
CPython's implementation), Access is possible if:
* Write access wasn't requested
* The file isn't read-only
* It's a directory (directories cannot be read-only on Windows)
PR-URL: https://github.com/libuv/libuv/pull/316
Reviewed-By: Bert Belder <bertbelder@gmail.com>
If CreateFileW succeeds, but _open_osfhandle fails, the handle must be closed.
PR-URL: https://github.com/libuv/libuv/pull/278
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Several windows .c files are including malloc.h unnecessarily.
This commit removes #includes that should have been removed
when we switched over to uv__malloc and uv__free (in commit
c272f1f1bc).
PR-URL: https://github.com/libuv/libuv/pull/270
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
In the code path for pipe blocking writes, WriteFile is already
posting a completion packet to the I/O completion port.
POST_COMPLETION_FOR_REQ was causing the same request to get
returned twice by GetCompletionStatusEx.
Also on the same code path, we were waiting on the wrong event.
PR-URL: https://github.com/libuv/libuv/pull/238
Reviewed-By: Bert Belder <bertbelder@gmail.com>
With uv_replace_allocator, it's possible to override the default
memory allocator's malloc and free calls with functions of the user's
choosing. This allows libuv to interoperate with projects requiring a
custom memory allocator.
Internally, all calls to malloc and free have been replaced with
uv__malloc and uv__free, respectively. The uv__malloc and uv__free
functions call malloc and free unless they have been overridden by a
previous call to uv_replace_allocator.
As part of this change, the special aligned memory allocations
performed in src/win/fs-event.c have been replaced with standard
allocations. The 4-byte alignment being requested in this file was
unnecessary, since standard allocators already guarantee at least an
8-byte alignment.
PR-URL: https://github.com/libuv/libuv/pull/231
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
All the public structs and unions in the private fields in uv-win.h have
been named and all code accessing them updated, to comply to the C89
spec (which were previously causing warnings with the -pedantic flag).
PR-URL: https://github.com/libuv/libuv/pull/239
Reviewed-By: Andrius Bentkus <andrius.bentkus@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
Before this commit, UNIX returned -1 on failure. Windows sometimes
returned a UV_E* error code and sometimes a bogus status code, courtesy
of errno values not mapping to UV_E* error codes on that platform.
PR-URL: https://github.com/libuv/libuv/pull/204
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The reported bug is arguably a compiler bug - a non-static inline
function should be inlined inside the compilation unit but still
have external linkage - but the abundant use of 'inline' isn't
really necessary in the first place. Remove it.
Fixes: https://github.com/libuv/libuv/issues/191
PR-URL: https://github.com/libuv/libuv/pull/194
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
The req->addrinfow field contains the hints in that case, so we must not
free it.
This regression was introduced in f2bb8d3 by yours truly.
PR-URL: https://github.com/libuv/libuv/pull/171
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
libuv requires that the socket/fd is in non-blocking mode, so do it
internally so the user doesn't need to write platform specific code to
do so.
This also makes the API consistent with uv_{tcp,udp,pipe}_open, since
it's not required to pass the fd in non-blocking mode there either.
PR-URL: https://github.com/libuv/libuv/pull/136
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
All windows console writes are synchronous anyway, so there's no reason
for uv_try_write() to do nothing.
PR: https://github.com/libuv/libuv/pull/127
Reviewed-by: Saúl Ibarra Corretgé <saghul@gmail.com>
Using a static thread local variable to store the thread handle causes
crashes on Windows XP/2003 when libuv is loaded as a dynamic library.
With this patch, a TLS slot is allocated dynamically.
PR-URL: https://github.com/libuv/libuv/pull/82
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Introduce a uv_tty_mode_t enum for uv_tty_set_mode(), with backward
compatible values. Add a new mode UV_TTY_MODE_IO, which uses
cfmakeraw() internally.
PR-URL: https://github.com/libuv/libuv/pull/86
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
If pending I/O callbacks were ran before polling, do a zero timeout
poll.
PR-URL: https://github.com/libuv/libuv/pull/58
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The modes are not meant to be combined, and doing so may hide problems
in the future.
PR-URL: https://github.com/libuv/libuv/pull/58
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
FormatMessage can fail, e.g. with ERROR_MUI_FILE_NOT_FOUND. In this case
no error message was set and uv_dlerror wrongly returned "no error".
With this patch the fallback error message "error: <errorno>" is
generated when FormatMessage fails.
PR-URL: https://github.com/libuv/libuv/pull/59
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
When the user closes an uv_poll_t handle, there may still be an
outstanding AFD_POLL request. Libuv can't cancel this AFD_POLL request
directly, so it has to submit another which makes the the previous
poll request return.
Libuv completely forgets about the "canceling" AFD_POLL request, but
at some point in time it may complete and store its result somewhere in
memory.
Without this patch the result of the canceling poll request is written
somewhere on the stack, which sometimes causes stack corruption. This
patch ensures that the result is written to some static scratch space
where it can do no harm.
PR-URL: https://github.com/libuv/libuv/pull/49
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Marc Schlaich <marc.schlaich@gmail.com>
Reviewed-By: Saúl Ibarra Corretgé <saghul@gmail.com>
