Hi,
Stephen, thanks for highlighting this.
For the last few analysis runs I have been generating some automatic emails
from these summary emails and git blame. There is an example below.
I'd like to do this for all of the open defects but can't find a way to
generate a similar report for existing defects. Also, assigning defects within
the web app doesn't seem to email the assignee. The open source version of
Coverity scan doesn't seem to have a web services interface like the commercial
version (you get what you pay for) so I can't easily query it.
If anyone knows more about automating Coverity scan let me know.
But as Stephen says there are a lot of low-lying fruit that could be fixed:
http://scan.coverity.com/projects/dpdk-data-plane-development-kit
John.
P.S. Sample email based on Coverity report:
Hi,
This is an automated email in relation to a new Coverity static code analysis
issue in DPDK. Details of the issue are below.
The email has been sent to you because you have been identified as the author
or maintainer of the code where the defect appears.
There are several possible scenarios:
* The defect identified isn't a real issue: In this case you can edit the
defect online and change the defect "Classification" to "False Positive" or
"Intentional" and change the "Action" to "Ignore". You should also update
the "Severity", add yourself as the "Owner" and add a comment note.
* The defect is a real issue: In this case you should submit a patch to fix
the issues. The patch should include the following information in addition
to the usual comments and signoff:
Coverity issue: 120412
Fixes: b4aee0fb9c6d ("examples/ip_pipeline: reconfigure thread binding
dynamically")
In Coverity you should update the Classification, Severity, Action (to "Fix
required" or "Fix Submitted"), Owner and a Comment if necessary.
* The defect wasn't introduced by you. The line where the defect occurs may
not be the source of the defect. If this is the case then let the actual
author of the defect know by forwarding this email with a note or reply to
the sender of this automated email: <john.mcnamara at intel.com>
You can review the defects online at:
http://scan.coverity.com/projects/dpdk-data-plane-development-kit
If you aren't registered for the DPDK Coverity you can do so here:
http://scan.coverity.com/users/sign_up
Git commit data and Coverity defect information below.
Commit data
===========
Commit: examples/ip_pipeline: reconfigure thread binding dynamically
Id: b4aee0fb9c6d4fee771271d6c03a65dc27ba024a
Author: Piotr Azarewicz
Email: piotrx.t.azarewicz at intel.com
Date: Thu Oct 29 15:36:53 2015 +0100
Defect information
==================
/examples/ip_pipeline/thread_fe.c: 338 in app_pipeline_thread_cmd_push()
*** CID 120412: Code maintainability issues (SIZEOF_MISMATCH)
332 /* Check for available slots in the application commands array
*/
333 n_cmds = RTE_DIM(thread_cmds) - 1;
334 if (n_cmds > APP_MAX_CMDS - app->n_cmds)
335 return -ENOMEM;
336
337 /* Push thread commands into the application */
>>> CID 120412: Code maintainability issues (SIZEOF_MISMATCH)
>>> Passing argument "&app->cmds[app->n_cmds]" of type "cmdline_parse_ctx_t
>>> *" and argument "n_cmds * 8UL /* sizeof (cmdline_parse_ctx_t *) */" to
>>> function "memcpy" is suspicious. In this case, "sizeof (cmdline_parse_ctx_t
>>> *)" is equal to "sizeof (cmdline_parse_ctx_t)", but this is not a portable
>>> assumption.
338 memcpy(&app->cmds[app->n_cmds],
339 thread_cmds,
340 n_cmds * sizeof(cmdline_parse_ctx_t *));
341
342 for (i = 0; i < n_cmds; i++)
34
