You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
it is not certain that len will always be more than zero; thus it is possible to call this function with len set to zero and indeed packet is deinited without being allocated first
I have no idea why GCC's -ftrivial-auto-var-init=zero helps it find this Wmaybe-uninitialized, when such warning was already active.
Steps to reproduce the issue:
Build with cflags set to -ftrivial-auto-var-init=zero
Describe the results you received:
Build failure
Describe the results you expected:
Build passes
Additional information you deem important (e.g. issue happens only occasionally):
Asserting len, or checking len input value and exiting the function straight away should help the compiler here.
The text was updated successfully, but these errors were encountered:
Description
Compiling criu with -Wall -Werror -ftrivial-auto-var-init=zero using gcc-14 spots an uninitialized variable in crui/tls
In
criu/criu/tls.c
Line 195 in e7aefe4
it is not certain that len will always be more than zero; thus it is possible to call this function with len set to zero and indeed packet is deinited without being allocated first
I have no idea why GCC's -ftrivial-auto-var-init=zero helps it find this Wmaybe-uninitialized, when such warning was already active.
Steps to reproduce the issue:
Describe the results you received:
Build failure
Describe the results you expected:
Build passes
Additional information you deem important (e.g. issue happens only occasionally):
Asserting len, or checking len input value and exiting the function straight away should help the compiler here.
The text was updated successfully, but these errors were encountered: