[Issue] gcc 14.2.1 warning

[LaurentThomas]

Hi,

gcc 14.2.1 refuse to compile:

• you made -Werror
• src/u_websocket.c line 2117 memcpy() makes a warning

The warning is quite bad, it says you test: if (data_len_in && data_len_in <= (SIZE_MAX-4))
but memcpy() max size is SSIZE_MAX (that is smaller)

possible fix:
add #include <limits.h> and change the if to SSIZE_MAX

[babelouest]

Hello,

Thanks for reporting the issue. I've tried the suggested fix which does not break the tests, but I'm wondering if that's a good fix. In all the documentation I can find, it says that memcpy uses a size_t, I don't see that the max size is ssize_t anywhere.

I'm not suggesting it's a compiler bug but... Could it be a compiler bug?

Or more seriously, is there some memcpy documentation or limits I've missed somewhere?

[LaurentThomas]

Hi,
Possibly
It is Fedora 40 system, gcc version 14.2.1 20240801 (Red Hat 14.2.1-1)
the full message is ulfius/src/u_websocket.c:2117:7: error: ‘memcpy’ specified size between 18446744073709551612 and 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Werror=stringop-overflow=]

Nevertheless you are right, /usr/include/strings.h memcpy prototype is

extern void *memcpy (void *__restrict __dest, const void *__restrict __src,
                     size_t __n) __THROW __nonnull ((1, 2));

So, size_t (unsigned), not ssize_t (signed)

For this kind of issues, I don't add -Werror in my projects, even if i fully agree that authors must take care of warnings

[babelouest]

I've pushed the fix in the branch gcc-14.2.1-warning for now.

If the warning persists in the next gcc versions or appear in more cases, I'll merge the branch with master. I'll leave this issue open for now.

[babelouest]

Hello @LaurentThomas ,

I've seen this issue in other environments (Debian testing and Ubuntu 24.04 now).

Although, for some reason, the warning is raised when CMAKE_BUILD_TYPE=Debug (the default setup), but if I build with the cmake flag CMAKE_BUILD_TYPE=Release, the warning does not appear.

I don't know which one is right (I'm still wondering about the SSIZE_T check with memcpy), but it could be a workaround.