https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124451
--- Comment #3 from Kyrylo Sovailo <k.sovailo at gmail dot com> ---
Please consider the following comment the main text of the report:
Analyzer becomes worse at resolving boolean logic when it operates with 'bool'
from <stdbool.h> as opposed to 'typedef enum { false, true } bool'.
I can demonstrate it by compiling the source file. It compiles without warnings
with 'gcc -c -fPIC -std=c89 -fanalyzer bug.c -o bug.o -DMY_BOOL'. But 'gcc -c
-fPIC -std=c89 -fanalyzer bug.c -o bug.o' generates the following output:
```
bug.c: In function ‘bad’:
bug.c:17:12: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
17 | return 0;
| ^
‘bad’: event 1
|
|bug.c:14:15:
| 14 | char *p = malloc(1);
| | ^~~~~~~~~
| | |
| | (1) allocated here
|
‘bad’: events 2-4
|
|bug.c:16:8:
| 16 | if (!p_is_null) free(p);
| | ^
| | |
| | (2) following ‘false’ branch...
| 17 | return 0;
| | ~
| | |
| | (3) ...to here
| | (4) ‘p’ leaks here; was allocated at (1)
|
bug.c: In function ‘also_bad’:
bug.c:25:12: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
25 | return 0;
| ^
‘also_bad’: event 1
|
|bug.c:22:15:
| 22 | char *p = malloc(1);
| | ^~~~~~~~~
| | |
| | (1) allocated here
|
‘also_bad’: event 2
|
|bug.c:24:8:
| 24 | if (p_is_null == false) free(p);
| | ^
| | |
| | (2) following ‘false’ branch...
|
‘also_bad’: events 3-4
|
|bug.c:25:12:
| 25 | return 0;
| | ^
| | |
| | (3) ...to here
| | (4) ‘p’ leaks here; was allocated at (1)
|
bug.c: In function ‘also_also_bad’:
bug.c:32:33: warning: use of uninitialized value ‘value’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
32 | result = (luck ? value : 0) + 10;
| ~~~~~~~~~~~~~~~~~~~^~~~
‘also_also_bad’: events 1-5
|
| 30 | int value, result;
| | ^~~~~
| | |
| | (1) region created on stack here
| | (2) capacity: 4 bytes
| 31 | if (luck) value = 1;
| | ~
| | |
| | (3) following ‘false’ branch (when ‘luck == 0’)...
| 32 | result = (luck ? value : 0) + 10;
| | ~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (4) ...to here
| | (5) use of uninitialized value
‘value’ here
```
The source code includes good and bad functions. 'good' can be compiled with
both normal boolean and typedef boolean. 'bad' can be compiled with typedef
booleans only. As you can see, the only difference is the definition of the
bool. The bug exists in both C89, C99 and C23 modes (except that it can't be
compiled with C23 and -DMY_BOOL for obvious reasons).
I don't know if it's truly a bug but the behavior seems very counterintuitive.
GCC was compiled with '-pipe -march=x86-64 -mtune=generic -Werror=odr
-Werror=lto-type-mismatch -Werror=strict-aliasing -O2 -m64'
