[0.7.4] build failure with GCC 14 due to [-Wincompatible-pointer-types]

[tgurr]

Please check the following items and answer all the questions when reporting a bug,
otherwise it will be closed immediately.

• This is NOT a site-related "bugs", e.g. some site blocks me when using curl_cffi,
  UNLESS it has been verified that the reason is missing pieces in the impersonation.
• A code snippet that can reproduce this bug is provided, even if it's a one-liner.
• Version information will be pasted as below.

Describe the bug
Failure to build curl_cffi 0.7.4 with GCC >= 14 (14.2.0):

[...]
2025-01-09 23:03:33,371 root INFO building 'curl_cffi._wrapper' extension
2025-01-09 23:03:33,371 root INFO creating build/temp.linux-x86_64-cpython-312/build/temp.linux-x86_64-cpython-312
2025-01-09 23:03:33,372 root INFO creating build/temp.linux-x86_64-cpython-312/ffi
2025-01-09 23:03:33,372 root INFO x86_64-pc-linux-gnu-cc -march=native -O2 -pipe -march=native -O2 -pipe -fPIC -Iinclude -Iffi -I/usr/x86_64-pc-linux-gnu/include/python3.12 -c build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c -o build/temp.linux-x86_64-cpython-312/build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.o
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c: In function '_cffi_d_curl_ws_recv':
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:2071:35: error: passing argument 4 of 'curl_ws_recv' from incompatible pointer type [-Wincompatible-pointer-types]
 2071 |   return curl_ws_recv(x0, x1, x2, x3, x4);
      |                                   ^~
      |                                   |
      |                                   int *
In file included from include/curl/curl.h:3300,
                 from ffi/shim.h:5,
                 from build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:574:
include/curl/websockets.h:56:43: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'int *'
   56 |                                   size_t *recv,
      |                                   ~~~~~~~~^~~~
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:2071:39: error: passing argument 5 of 'curl_ws_recv' from incompatible pointer type [-Wincompatible-pointer-types]
 2071 |   return curl_ws_recv(x0, x1, x2, x3, x4);
      |                                       ^~
      |                                       |
      |                                       struct curl_ws_frame **
include/curl/websockets.h:57:64: note: expected 'const struct curl_ws_frame **' but argument is of type 'struct curl_ws_frame **'
   57 |                                   const struct curl_ws_frame **metap);
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c: In function '_cffi_f_curl_ws_recv':
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:2137:39: error: passing argument 4 of 'curl_ws_recv' from incompatible pointer type [-Wincompatible-pointer-types]
 2137 |   { result = curl_ws_recv(x0, x1, x2, x3, x4); }
      |                                       ^~
      |                                       |
      |                                       int *
include/curl/websockets.h:56:43: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'int *'
   56 |                                   size_t *recv,
      |                                   ~~~~~~~~^~~~
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:2137:43: error: passing argument 5 of 'curl_ws_recv' from incompatible pointer type [-Wincompatible-pointer-types]
 2137 |   { result = curl_ws_recv(x0, x1, x2, x3, x4); }
      |                                           ^~
      |                                           |
      |                                           struct curl_ws_frame **
include/curl/websockets.h:57:64: note: expected 'const struct curl_ws_frame **' but argument is of type 'struct curl_ws_frame **'
   57 |                                   const struct curl_ws_frame **metap);
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c: In function '_cffi_d_curl_ws_send':
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:2152:35: error: passing argument 4 of 'curl_ws_send' from incompatible pointer type [-Wincompatible-pointer-types]
 2152 |   return curl_ws_send(x0, x1, x2, x3, x4, x5);
      |                                   ^~
      |                                   |
      |                                   int *
include/curl/websockets.h:71:58: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'int *'
   71 |                                   size_t buflen, size_t *sent,
      |                                                  ~~~~~~~~^~~~
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c: In function '_cffi_f_curl_ws_send':
build/temp.linux-x86_64-cpython-312/curl_cffi._wrapper.c:2219:39: error: passing argument 4 of 'curl_ws_send' from incompatible pointer type [-Wincompatible-pointer-types]
 2219 |   { result = curl_ws_send(x0, x1, x2, x3, x4, x5); }
      |                                       ^~
      |                                       |
      |                                       int *
include/curl/websockets.h:71:58: note: expected 'size_t *' {aka 'long unsigned int *'} but argument is of type 'int *'
   71 |                                   size_t buflen, size_t *sent,
      |                                                  ~~~~~~~~^~~~
[...]

To Reproduce

1. Have GCC >= 14
2. Try to build curl_cffi

Expected behavior
No build failure.

Versions

• OS: linux x64
• curl_cffi version 0.7.4

Additional context
See the GCC 14 porting guide about -Werror=incompatible-pointer-types (https://gcc.gnu.org/gcc-14/porting_to.html#incompatible-pointer-types) with GCC 14 the warnings became errors:

GCC no longer allows implicitly casting all pointer types to all other pointer types.

Complete build log: curl-cffi-0.7.4.build.log

[eternaleye]

To add some specifics:

Current signatures in ffi/cdef.c:

curl_cffi/ffi/cdef.c

Lines 59 to 60 in 3ff5d83

	int curl_ws_recv(void *curl, void *buffer, int buflen, int *recv, struct curl_ws_frame **meta);
	int curl_ws_send(void *curl, void *buffer, int buflen, int *sent, int fragsize, unsigned int sendflags);

Signatures according to the libcurl docs for curl_ws_recv and curl_ws_send:

CURLcode curl_ws_recv(CURL *curl, void *buffer, size_t buflen, size_t *recv, const struct curl_ws_frame **meta);
CURLcode curl_ws_send(CURL *curl, const void *buffer, size_t buflen, size_t *sent, curl_off_t fragsize, unsigned int flags);

CFFI itself has built-in support for size_t:

https://github.com/python-cffi/cffi/blob/v1.17.1/cffi/backend_ctypes.py#L291-L298

Accordingly, buflen, recv, and sent should probably be updated to use size_t; there's no reason to avoid it that I can see, even though the compiler isn't currently complaining about buflen.

In the case of recv and sent, because the pointer passed (int*) is to a potentially (e.g. on most 64-bit platforms...) smaller type than size_t and is written through by curl, this could also result in out-of-bounds writes if left unchanged; this problem was present all along even without GCC 14 being stricter.

Then, there's the missing const on meta in curl_ws_recv and on buffer in curl_ws_send, which should be solved by simply adding it, though only the former is currently erroring.

curl_off_t is a more complicated topic (due to curl defining its own nuanced fallback logic for it to always be 64-bit unless that's truly impossible), but as it's only used as a by-value input here promotion from 32-bit int when it happens should be fine, and merely prevent users from specifying particularly large values.

[lexiforest]

Thanks, but I do recall some issues will appear if I use these aliased types, like curl_off_t. We will need to experiment to find out the extent we can support here. PRs are always welcome.

[eternaleye]

That's why curl_off_t is the one I was suggesting might be best to leave as is, exactly because it's got more weirdness, yeah. By contrast, size_t is much more predictable due to being defined by the standard and directly handled by cffi itself.

I didn't mention CURLcode at all, since as an enum it's likely a lot more work to handle directly, and int is in fact the default storage type for enums, so it's an entirely valid substitution.