NetBSD Problem Report #42654

From www@NetBSD.org  Wed Jan 20 20:36:56 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 22F9263C550
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 20 Jan 2010 20:36:56 +0000 (UTC)
Message-Id: <20100120203655.E88E163C54F@www.NetBSD.org>
Date: Wed, 20 Jan 2010 20:36:55 +0000 (UTC)
From: joel.sherrill@gmail.com
Reply-To: joel.sherrill@gmail.com
To: gnats-bugs@NetBSD.org
Subject: Coverity Scan Issues on ls.c
X-Send-Pr-Version: www-1.0

>Number:         42654
>Category:       bin
>Synopsis:       Coverity Scan Issues on ls.c
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jan 20 20:40:00 +0000 2010
>Closed-Date:    Sun Jul 13 01:21:17 +0000 2014
>Last-Modified:  Sun Jul 13 01:21:17 +0000 2014
>Originator:     Joel Sherrill
>Release:        NA
>Organization:
RTEMS (http:://www.rtems.org
>Environment:
NA
>Description:
The RTEMS Project is using some code pulled in from NetBSD.  We are also part of the Coverity Scan project for free software projects.  We have two Coverity "results" on ls.c CVS id 1.58 which are reported as dead code. I compared that version against the head (20 Jan 2010) and these issues do not look fixed. Looking at the code, I am completely unsure of the intent but both look like bugs.

I can provide full versions of the Coverity Scan logs via email and am happy to rerun if provided fixes.  We just need someone more familiar with the code to help fix these two.  T

Please. :)
>How-To-Repeat:
This is a fragment of one of the reports.  Sorry if the cut and paste does not look nice.

Event dead_error_condition: On this path, the condition "flags != 0" could not be true
Event const: After this line, the value of "flags" is equal to 0
Event new_values: Conditional "flags != 0"
Also see events: [dead_error_begin][const][const][assignment][new_values]

630  					 if (f_flags && flags) {

Event dead_error_begin: Cannot reach dead code beginning here
Also see events: [dead_error_condition][const][const][assignment][new_values]

631  						np->flags = &np->data[ulen + glen + 2];
632  					  	(void)strcpy(np->flags, flags);

>Fix:
Unknown

>Release-Note:

>Audit-Trail:
From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org
Cc: netbsd-bugs@NetBSD.org
Subject: Re: bin/42654: Coverity Scan Issues on ls.c
Date: Thu, 28 Jan 2010 20:19:02 +0200

 On Wed, 20 Jan 2010, joel.sherrill@gmail.com wrote:
 > The RTEMS Project is using some code pulled in from NetBSD.  We are
 > also part of the Coverity Scan project for free software projects.  We
 > have two Coverity "results" on ls.c CVS id 1.58 which are reported as
 > dead code. [...]

 > 630  					 if (f_flags && flags) {

 This line does not appear in revision 1.58 of NetBSD's src/bin/ls/ls.c.

 > 631  						np->flags = &np->data[ulen + glen + 2];
 > 632  					  	(void)strcpy(np->flags, flags);

 Lines with content like this do appear, as lines 570 and 571 of revision
 1.58 of NetBSD's src/bin/ls/ls.c.  However, the fact that the line
 numbers are different indicates that the file you checked is not the
 file from NetBSD.  It's not at all clear, from what you have told us so
 far, that your Coverity report applies to NetBSD's version of ls.c.

 --apb (Alan Barrett)

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 12 Jul 2014 19:59:16 +0000
State-Changed-Why:
Is this still an issue? (And also, a question was asked back in 2010, and
it would be nice to get it answered, since there's no point us trying to
fix some other random branch of ls that came from somewhere else.)


From: Dave Huang <khym@azeotrope.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: bin/42654 (Coverity Scan Issues on ls.c)
Date: Sat, 12 Jul 2014 16:36:56 -0500

 This seems to be related to 
 http://git.rtems.org/rtems/commit/cpukit/libmisc/shell/main_ls.c?id=8bffc40b3a6b62ae993123c5fc16e9e2c5800ad8

 AFAICT, it doesn't affect NetBSD... the problem with the RTEMS code is 
 that the previous "if (f_flags)" block that set "flags" (line 552 of 
 NetBSD's ls.c r1.58) was removed via "#if RTEMS_REMOVED", but the block 
 that uses "flags" (line 569 of NetBSD's ls.c) was not similarly #if'ed 
 out. Since NetBSD didn't remove the first block, there's no problem in 
 the second block.

State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 13 Jul 2014 01:21:17 +0000
State-Changed-Why:
Not our fault.

thanks for checking that, btw.


>Unformatted:

Home	PR Database Search