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

incompatible-pointer-types in c_generated_functions.c #159

Closed
olafhering opened this issue Sep 3, 2024 · 7 comments
Closed

incompatible-pointer-types in c_generated_functions.c #159

olafhering opened this issue Sep 3, 2024 · 7 comments

Comments

@olafhering
Copy link

GCC 14 complains about incompatible pointer types:

[   13s] + dune installed-libraries
[   13s] bigarray               (version: 4.14.2)
[   13s] bigarray-compat        (version: 1.1.0)
[   13s] bytes                  (version: 4.14.2)
[   13s] compiler-libs          (version: 4.14.2)
[   13s] compiler-libs.bytecomp (version: 4.14.2)
[   13s] compiler-libs.common   (version: 4.14.2)
[   13s] compiler-libs.optcomp  (version: 4.14.2)
[   13s] compiler-libs.toplevel (version: 4.14.2)
[   13s] ctypes                 (version: 0.23.0)
[   13s] ctypes-foreign         (version: 0.23.0)
[   13s] ctypes.stubs           (version: 0.23.0)
[   13s] ctypes.top             (version: 0.23.0)
[   13s] dynlink                (version: 4.14.2)
[   13s] integers               (version: 0.7.0)
[   13s] integers.top           (version: 0.7.0)
[   13s] ocamldoc               (version: [distributed with OCaml])
[   13s] raw_spacetime          (version: 4.14.2)
[   13s] seq                    (version: 4.14.2)
[   13s] stdlib                 (version: 4.14.2)
[   13s] stdlib-shims           (version: 0.3.0)
[   13s] str                    (version: 4.14.2)
[   13s] threads                (version: 4.14.2)
[   13s] threads.none           (version: 4.14.2)
[   13s] threads.posix          (version: 4.14.2)
[   13s] uchar                  (version: 4.14.2)
[   13s] unix                   (version: 4.14.2)

[   15s] File "_build/.dune/default/src/c/dune", line 12, characters 9-30:
[   15s] 12 |   (names c_generated_functions helpers)
[   15s]               ^^^^^^^^^^^^^^^^^^^^^
[   15s] Command [137] exited with code 1:
[   15s] $ (cd _build/default/src/c && /usr/bin/gcc-14 -O2 -fno-strict-aliasing -fwrapv -pthread -Werror=implicit-function-declaration -Werror=return-type -Wno-deprecated-declarations -fPIC -pipe -D_FILE_OFFSET_BITS=64 -O2 -fno-strict-aliasing -fwrapv -pthread -Werror=implicit-function-declaration -Werror=return-type -Wno-deprecated-declarations -fPIC -pipe -g -I /usr/lib64/ocaml -I /usr/lib64/ocaml/bigarray-compat -I /usr/lib64/ocaml/ctypes -I /usr/lib64/ocaml/integers -I /usr/lib64/ocaml/stdlib-shims -I /usr/lib64/ocaml/threads -I . -o c_generated_functions.o -c c_generated_functions.c)
[   15s] c_generated_functions.c: In function ‘luv_stub_156_luv_get_getnameinfo_trampoline’:
[   15s] c_generated_functions.c:1177:4: error: initialization of ‘void (*)(uv_getnameinfo_t *, int,  const char *, const char *)’ {aka ‘void (*)(struct uv_getnameinfo_s *, int,  const char *, const char *)’} from incompatible pointer type ‘luv_getnameinfo_cb’ {aka ‘void (*)(struct uv_getnameinfo_s *, int,  char *, char *)’} [-Wincompatible-pointer-types]
[   15s]  1177 |    luv_get_getnameinfo_trampoline();
[   15s]       |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[   15s] c_generated_functions.c: In function ‘luv_stub_157_luv_getnameinfo’:
[   15s] c_generated_functions.c:1189:43: error: passing argument 3 of ‘luv_getnameinfo’ from incompatible pointer type [-Wincompatible-pointer-types]
[   15s]  1189 |    int x954 = luv_getnameinfo(x947, x948, x949, x950, x951);
[   15s]       |                                           ^~~~
[   15s]       |                                           |
[   15s]       |                                           void (*)(uv_getnameinfo_t *, int,  const char *, const char *) {aka void (*)(struct uv_getnameinfo_s *, int,  const char *, const char *)}
[   15s] In file included from c_generated_functions.c:8:
[   15s] helpers.h:177:64: note: expected ‘luv_getnameinfo_cb’ {aka ‘void (*)(struct uv_getnameinfo_s *, int,  char *, char *)’} but argument is of type ‘void (*)(uv_getnameinfo_t *, int,  const char *, const char *)’ {aka ‘void (*)(struct uv_getnameinfo_s *, int,  const char *, const char *)’}
[   15s]   177 |     uv_loop_t *loop, uv_getnameinfo_t *req, luv_getnameinfo_cb getnameinfo_cb,
[   15s]       |                                             ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~
@aantron
Copy link
Owner

aantron commented Sep 3, 2024

Thanks!

For GCC 14, it looks like Luv will have to upgrade to ctypes 0.23.0 to use its ability to generate const-correct code, or work around this otherwise, perhaps with some more casts. See:

@aantron
Copy link
Owner

aantron commented Sep 4, 2024

Even more tricky, this is likely caused by ctypes 0.23.0 now translating string as const char*, which is the more correct behavior, but it makes the wrappers we currently have for handling ctypes' previous behavior of translating string as char* not only redundant, but harmful, causing these new warnings when we try to bind to the previous wrappers, whose whole purpose was to cast char* to const char*. I will delete them and require ctypes 0.23.0.

@aantron
Copy link
Owner

aantron commented Sep 4, 2024

Would you be able to try this with the Luv commit ad7f953, from branch getnameinfo-constness, which is linked above? It makes the build warning-clean again on my machine, with ctypes 0.23.0.

@olafhering
Copy link
Author

ad7f953 does indeed work. Thank you.

@aantron
Copy link
Owner

aantron commented Sep 5, 2024

Thanks! Let me know if you'd like a release to opam.

@olafhering
Copy link
Author

Well, if you don't mind: release early, release often.

With a new release I would be able to point the Haxe people to this issue, so that they can start porting their code to 0.5.13, or newer.

@aantron
Copy link
Owner

aantron commented Sep 5, 2024

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

No branches or pull requests

2 participants