Switch from old-style ASSERT macro to new-style ASSERT_EQ,... macros.
Using new-style macros makes it easier to debug test failures
Fixes: https://github.com/libuv/libuv/issues/2974
Pass the loop to MAKE_VALGRIND_HAPPY() so it's explicit on which loop
needs to be cleaned up. Since it asserts on uv_loop_close(), need to
remove a couple of those that were being done before the call.
Cleanup where loop was assigned, so the entire test either uses loop or
uv_default_loop(). Not both.
Also take care of any reqs that may have been left uncleaned.
Passing or returning structs as values makes life hard for people that
work with libuv through a foreign function interface. Switch to a
pointer-based approach.
Fixes#684.
Passing or returning structs as values makes life hard for people that
work with libuv through a foreign function interface. Switch to a
pointer-based approach.
Fixes#684.
Passing or returning structs as values makes life hard for people that
work with libuv through a foreign function interface. Switch to a
pointer-based approach.
Fixes#684.
This means we no longer have to strip the high bit from the process exit
code on Windows, which is problematic because an unhandled SEH exception
can make a process exit with a status code that has the high bit set.
This commit changes the libuv API to return error codes directly rather
than storing them in a loop-global field.
A code snippet like this one:
if (uv_foo(loop) < 0) {
uv_err_t err = uv_last_error(loop);
fprintf(stderr, "%s\n", uv_strerror(err));
}
Should be rewritten like this:
int err = uv_foo(loop);
if (err < 0)
fprintf(stderr, "%s\n", uv_strerror(err));
The rationale for this change is that it should make creating bindings
for other languages a lot easier: dealing with struct return values is
painful with most FFIs and often downright buggy.
This changes the prototype of uv_run() from:
int uv_run(uv_loop_t* loop);
To:
int uv_run(uv_loop_t* loop, uv_run_mode mode);
Where `mode` is UV_RUN_DEFAULT, UV_RUN_ONCE or UV_RUN_NOWAIT.
Fixes#683.
Replace `void f()` with `void f(void)`; the former means "a function
that takes any number of arguments, including none" while the latter
is what is actually intended: a function taking no arguments.
The first form also isn't strictly conforming ANSI/ISO C.
Previously the only option was to create a pipe or an ipc channel. This
patch makes it possible to inherit a handle that is already open in the
parent process. It also makes it possible to set more than just stdin,
stdout and stderr.
Previously the only option was to create a pipe or an ipc channel. This
patch makes it possible to inherit a handle that is already open in the
parent process. There is also room for setting more than just stdin,
stdout and stderr, although this is not supported yet.
