Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libuv 1.42 bindings #464

Open
wants to merge 118 commits into
base: master
Choose a base branch
from

Conversation

RealyUniqueName
Copy link
Member

@RealyUniqueName RealyUniqueName commented Aug 4, 2021

See HaxeFoundation/haxe#10342

I'm unexpirienced with C/C++. Especially with memory management. Please, review thoroughly.

Questions to figure out:

  • - how to construct and throw instances of hl.uv.UVException (see libuv 1.42 bindings #464 (comment))
  • - how to construct Haxe's strings and arrays from C without the need for wrapping code on Haxe side. (see libuv 1.42 bindings #464 (comment))
  • - hashlink has no type for uint64_t. Currently all occurences of uint64_t are mapped to int64
  • - I64 is not fully supported (e.g. haxe code i64_a == i64_b produces jit error)
  • - how to provide defined constant values for Haxe code (e.g. how to make values of enum abstract UVError(Int) to be the same as corresponding UV_E* constants) (see libuv 1.42 bindings #464 (comment))

@RealyUniqueName
Copy link
Member Author

RealyUniqueName commented Sep 6, 2021

@ncannasse this one is ready for review. If you're using github interface you can jump right to uv.c file as everything prior to this file is just a libuv 1.9->1.42 update.

OSX ci failures are not related to this PR.

@Simn
Copy link
Member

Simn commented Apr 11, 2022

how to provide defined constant values for Haxe code (e.g. how to make values of enum abstract UVError(Int) to be the same as corresponding UV_E* constants)

This requires to copy / paste the values from C headers to Haxe headers. These values are very rarely changed in C implementation, I haven't had a case that was changing them depending on library version.

Something to point out here is that it's not so much about the values changing, the real problem is that these values may vary depending on the OS. See http://docs.libuv.org/en/v1.x/errors.html:

Note Implementation detail: on Unix error codes are the negated errno (or -errno), while on Windows they are defined by libuv to arbitrary negative numbers.

In the old asys implementation for eval we had this on the C-side:

CAMLprim value hx_get_errno(value unit) {
	CAMLparam1(unit);
	const char* names[] = {"E2BIG", "EACCES", "EADDRINUSE", "EADDRNOTAVAIL", "EAFNOSUPPORT", "EAGAIN", "EAI_ADDRFAMILY", "EAI_AGAIN", "EAI_BADFLAGS", "EAI_BADHINTS", "EAI_CANCELED", "EAI_FAIL", "EAI_FAMILY", "EAI_MEMORY", "EAI_NODATA", "EAI_NONAME", "EAI_OVERFLOW", "EAI_PROTOCOL", "EAI_SERVICE", "EAI_SOCKTYPE", "EALREADY", "EBADF", "EBUSY", "ECANCELED", "ECHARSET", "ECONNABORTED", "ECONNREFUSED", "ECONNRESET", "EDESTADDRREQ", "EEXIST", "EFAULT", "EFBIG", "EHOSTUNREACH", "EINTR", "EINVAL", "EIO", "EISCONN", "EISDIR", "ELOOP", "EMFILE", "EMSGSIZE", "ENAMETOOLONG", "ENETDOWN", "ENETUNREACH", "ENFILE", "ENOBUFS", "ENODEV", "ENOENT", "ENOMEM", "ENONET", "ENOPROTOOPT", "ENOSPC", "ENOSYS", "ENOTCONN", "ENOTDIR", "ENOTEMPTY", "ENOTSOCK", "ENOTSUP", "EPERM", "EPIPE", "EPROTO", "EPROTONOSUPPORT", "EPROTOTYPE", "ERANGE", "EROFS", "ESHUTDOWN", "ESPIPE", "ESRCH", "ETIMEDOUT", "ETXTBSY", "EXDEV", "UNKNOWN", "EOF", "ENXIO", "EMLINK", "EHOSTDOWN", "EOTHER"};
	int values[] = {UV_E2BIG, UV_EACCES, UV_EADDRINUSE, UV_EADDRNOTAVAIL, UV_EAFNOSUPPORT, UV_EAGAIN, UV_EAI_ADDRFAMILY, UV_EAI_AGAIN, UV_EAI_BADFLAGS, UV_EAI_BADHINTS, UV_EAI_CANCELED, UV_EAI_FAIL, UV_EAI_FAMILY, UV_EAI_MEMORY, UV_EAI_NODATA, UV_EAI_NONAME, UV_EAI_OVERFLOW, UV_EAI_PROTOCOL, UV_EAI_SERVICE, UV_EAI_SOCKTYPE, UV_EALREADY, UV_EBADF, UV_EBUSY, UV_ECANCELED, UV_ECHARSET, UV_ECONNABORTED, UV_ECONNREFUSED, UV_ECONNRESET, UV_EDESTADDRREQ, UV_EEXIST, UV_EFAULT, UV_EFBIG, UV_EHOSTUNREACH, UV_EINTR, UV_EINVAL, UV_EIO, UV_EISCONN, UV_EISDIR, UV_ELOOP, UV_EMFILE, UV_EMSGSIZE, UV_ENAMETOOLONG, UV_ENETDOWN, UV_ENETUNREACH, UV_ENFILE, UV_ENOBUFS, UV_ENODEV, UV_ENOENT, UV_ENOMEM, UV_ENONET, UV_ENOPROTOOPT, UV_ENOSPC, UV_ENOSYS, UV_ENOTCONN, UV_ENOTDIR, UV_ENOTEMPTY, UV_ENOTSOCK, UV_ENOTSUP, UV_EPERM, UV_EPIPE, UV_EPROTO, UV_EPROTONOSUPPORT, UV_EPROTOTYPE, UV_ERANGE, UV_EROFS, UV_ESHUTDOWN, UV_ESPIPE, UV_ESRCH, UV_ETIMEDOUT, UV_ETXTBSY, UV_EXDEV, UV_UNKNOWN, UV_EOF, UV_ENXIO, UV_EMLINK, UV_EHOSTDOWN, 0};
	CAMLreturn(build_fields(sizeof(values) / sizeof(values[0]), names, values));
}

This would then get assigned in a way that would match the native representation of an extern enum abstract UVErrorType(Int).

This should be possible for HL as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants