[dpdk-dev] [PATCH v4] net/tap: fix coverity warning on strncpy

Wiles, Keith keith.wiles at intel.com
Fri Feb 17 17:53:51 CET 2017


> On Feb 17, 2017, at 10:48 AM, Yigit, Ferruh <ferruh.yigit at intel.com> wrote:
> 
> On 2/17/2017 4:34 PM, Wiles, Keith wrote:
>> 
>>> On Feb 17, 2017, at 10:21 AM, Yigit, Ferruh <ferruh.yigit at intel.com> wrote:
>>> 
>>> On 2/17/2017 3:43 PM, Keith Wiles wrote:
>>>> Calling strncpy with a maximum size argument of 16 bytes on destination
>>>> array "ifr.ifr_ifrn.ifrn_name" of size 16 bytes might leave the
>>>> destination string unterminated.
>>>> 
>>>> Signed-off-by: Keith Wiles <keith.wiles at intel.com>
>>> 
>>>   net/tap: fix possibly unterminated string
>>> 
>>>   Coverity issue: 1407499
>>>   Fixes: 6b38b2725cdb ("net/tap: fix multi-queue support")
>>>   Cc: stable at dpdk.org
>>> 
>>> Applied to dpdk-next-net/master, thanks.
>>> 
>>> 
>>> (Updates:
>>> - patch title:
>>> It is preferred to mention from problem solved instead of the tool that
>>> found it.
>>> 
>>> - Added coverity tag:
>>> This helps to trace coverity issues, defined syntax is:
>>> 
>>>   Coverity issue: xxx
>>>   Fixes: yyyy
>>> 
>>> - Added Cc: tag for stable tree:
>>> In case stable tree wants get this patch, to make patch visible.
>> 
>> I agree this is good, but to many rules not listed or checked in the tools. We need a much easier method to submit patches in the format that is defined and checked.
>> 
>> Today it is way to hard to know every little internal format for every type of patch. We need to fix this problem to make it easier to submit patches to dpdk.org, we can not continue like this as we grow it will become way to much work for the repo maintainers and the submitter.
> 
> That is why I am documenting what has been changed and the reasoning in
> the mail, so I am hoping this is helping others that following the mail
> list sync about rules. Also gives a discussion medium about rules..

Great, but we need to document this on the web site not in email. We can not expect someone (or a new person) to read millions of emails to find these hidden gems, right?

> 
>> 
>> Using a better tool then submitting via email seems like a better solution as long as we can add the given checks to the tool. Using a tools should also reduce the email traffic for most everyone, but we need to allow anyone to ask for all of the commits to the repo or pull requests like patches.
>> 
>> How can we handle these types of issues in the future?
>> 
>>> )
>> 
>> Regards,
>> Keith

Regards,
Keith



More information about the dev mailing list