src/openvt.c:386: 'pid' may be used uninitialized
Hi,
I've found this bug using a static analyzer (slightly improved GCC).
Consider variable pid in function main from src/openvt.c:
src/openvt.c:166: int opt, pid, i;
src/openvt.c:303: if (direct_exec || ((pid = fork()) == 0)) {
src/openvt.c:386: if (pid < 0)src/openvt.c:393: waitpid(pid, &retval, 0);
If direct_exec is TRUE, then pid doesn't get initialized, but it is used outside the conditional regardless of that.
Signature · 1 line
Vlad
Quoted 6 lines · Vladislav Ivanishin
Hi,
I've found this bug using a static analyzer (slightly improved GCC).
Consider variable
pidin function main fromsrc/openvt.c:
Quoted 7 lines
src/openvt.c:166: int opt, pid, i; src/openvt.c:303: if (direct_exec || ((pid = fork()) == 0)) { src/openvt.c:386: if (pid < 0)
src/openvt.c:393:waitpid(pid, &retval, 0);If
direct_execis TRUE, then pid doesn't get initialized, but it is used outside the conditional regardless of that.
This is not a bug. If direct_exec is TRUE we will never be on line 386. To make linter happy, I’ll make pid = 0.
Thanks!
Signature · 1 line
Rgrds, legion
Sorry, I didn't get your reply (not sure what the actual reason is, but it seems as if you've only replied to the list, and I am not subscribed) so I've just read it today in the archives.
Quoted 12 lines · Vladislav Ivanishin
Quoted 11 lines
Hi,
I've found this bug using a static analyzer (slightly improved GCC).
Consider variable
pidin function main fromsrc/openvt.c:src/openvt.c:166: int opt, pid, i; src/openvt.c:303: if (direct_exec || ((pid = fork()) == 0)) { src/openvt.c:386: if (pid < 0)
src/openvt.c:393:waitpid(pid, &retval, 0);
Quoted 4 lines
Quoted 2 lines
If
direct_execis TRUE, then pid doesn't get initialized, but it is used outside the conditional regardless of that.This is not a bug. If
direct_execis TRUE we will never be on line 386.
Oh, I didn't realize that; my bad, thanks for pointing this out.
The real issue preventing the analyzer (i.e. the compiler) from seeing this as well is kbd_error lacking the noreturn attribute.
Quoted 1 line
To make linter happy, I’ll make pid = 0.
So a more proper fix would be adding the attribute in the header file. It would also make other compiler analyses/optimizations more effective.
Signature · 1 line
Vlad
Quoted 4 lines
Thanks!
Signature · 1 line
Rgrds, legion
Quoted 23 lines · Vladislav Ivanishin
Sorry, I didn't get your reply (not sure what the actual reason is, but it seems as if you've only replied to the list, and I am not subscribed) so I've just read it today in the archives.
Quoted 12 lines · Vladislav Ivanishin
Quoted 11 lines
Hi,
I've found this bug using a static analyzer (slightly improved GCC).
Consider variable
pidin function main fromsrc/openvt.c:src/openvt.c:166: int opt, pid, i; src/openvt.c:303: if (direct_exec || ((pid = fork()) == 0)) { src/openvt.c:386: if (pid < 0)
src/openvt.c:393:waitpid(pid, &retval, 0);Quoted 4 lines
Quoted 2 lines
If
direct_execis TRUE, then pid doesn't get initialized, but it is used outside the conditional regardless of that.This is not a bug. If
direct_execis TRUE we will never be on line 386.Oh, I didn't realize that; my bad, thanks for pointing this out.
Quoted 7 lines
The real issue preventing the analyzer (i.e. the compiler) from seeing this as well is
kbd_errorlacking the noreturn attribute.Quoted 1 line
To make linter happy, I’ll make pid = 0.
So a more proper fix would be adding the attribute in the header file. It would also make other compiler analyses/optimizations more effective.
I already did it recently:
https://github.com/legionus/kbd/commit/93689a202aeae8707c59c67aa1af5a36c27fba6c
Signature · 1 line
Rgrds, legion