Lawrence Livermore National Labs recently ran the source code
analysis tool Coverity over the e2fsprogs-1.39 source to see
if it would identify any significant bugs. The analysis
turned up 38 mostly minor issues which are enumerated here
with patches. We went through and resolved these issues
but would love to see these mostly minor changes reviewed
and commited upstream.
Thanks,
Brian Behlendorf <[email protected]>, and
Herb Wartens <[email protected]>
-----------------------------------------------------------------------------
Coverity ID: 2: Deadcode
Looks like ss_current_request is a macro that will set code to 0. This test
will always be false. I will remove this error case.
Index: e2fsprogs+chaos/lib/ss/help.c
===================================================================
--- e2fsprogs+chaos.orig/lib/ss/help.c
+++ e2fsprogs+chaos/lib/ss/help.c
@@ -49,10 +49,6 @@ void ss_help (argc, argv, sci_idx, info_
register ss_data *info;
request_name = ss_current_request(sci_idx, &code);
- if (code != 0) {
- ss_perror(sci_idx, code, "");
- return; /* no ss_abort_line, if invalid invocation */
- }
if (argc == 1) {
ss_list_requests(argc, argv, sci_idx, info_ptr);
return;
On Fri, Feb 09, 2007 at 06:11:17PM -0800, Brian D. Behlendorf wrote:
> Looks like ss_current_request is a macro that will set code to 0. This test
> will always be false. I will remove this error case.
The ss library is pretty stable, yes, but it's a bad idea to remove an
error check which is mandated by the interface defintion; what if the
implementation changes in the future?
Probably the better way to shut up coverity in this case is to replace
the current implementation of ss_current_request with a C version
which checks to make sure sci_idx is valid (as opposed to blindly
indexing off the array and potentially causing a seg fault), and
returning EINVAL if sci_idx is invalid.
I will NOT do this fixup now, but I will queue it in a future
(low-priority) TODO list. Fixes to do this are welcome.
- Ted