NetBSD Problem Report #36668

From martin@duskware.de  Fri Jul 20 09:02:02 2007
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id A562763B93E
	for <gnats-bugs@gnats.netbsd.org>; Fri, 20 Jul 2007 09:02:02 +0000 (UTC)
Message-Id: <20070720085903.5568B63B93E@narn.NetBSD.org>
Date: Fri, 20 Jul 2007 08:59:03 +0000 (UTC)
From: mccratch@gmx.net
Reply-To: mccratch@gmx.net
To: netbsd-bugs-owner@NetBSD.org
Subject: bogus complaints about sys/endian.h code when running lint -aa
X-Send-Pr-Version: www-1.0

>Number:         36668
>Category:       lib
>Synopsis:       bogus complaints about sys/endian.h code when running lint -aa
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    rillig
>State:          closed
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Jul 20 09:05:00 +0000 2007
>Closed-Date:    Thu May 26 09:37:40 +0000 2022
>Last-Modified:  Thu May 26 20:20:02 +0000 2022
>Originator:     Matthias Kretschmer
>Release:        4.0_BETA2
>Organization:
>Environment:
NetBSD tiger 4.0_BETA2 NetBSD 4.0_BETA2 (GENERIC.MP) #4: Tue Jun  5 15:52:40 CEST 2007
>Description:
"lint -aa" complains about "may loose accuracy" for sys/endian.h.
This is no bug at all, just annoying when using lint -aa.
>How-To-Repeat:
$ cat > test.c << EOF
#include <sys/endian.h>
EOF
$ lint -aa test.c
>Fix:
Add explicit typecasts (e.g. applying the following patch to sys/endian.h).
The semantics of the code aren't touched as the compiler has to implicitly cast the values to the given types when running this code.

--- endian.h.orig    2005-02-03 20:16:10.000000000 +0100
+++ endian.h   2007-07-20 10:23:33.000000000 +0200
@@ -190,8 +190,8 @@
 {
        uint8_t *p = (uint8_t *)buf;

-       p[0] = ((unsigned)u >> 8) & 0xff;
-       p[1] = u & 0xff;
+       p[0] = (uint8_t)(((unsigned)u >> 8) & 0xff);
+       p[1] = (uint8_t)(u & 0xff);
 }

 static __inline void __unused
@@ -199,8 +199,8 @@
 {
        uint8_t *p = (uint8_t *)buf;

-       p[0] = u & 0xff;
-       p[1] = ((unsigned)u >> 8) & 0xff;
+       p[0] = (uint8_t)(u & 0xff);
+       p[1] = (uint8_t)(((unsigned)u >> 8) & 0xff);
 }

 static __inline uint16_t __unused
@@ -208,7 +208,7 @@
 {
        const uint8_t *p = (const uint8_t *)buf;

-       return ((p[0] << 8) | p[1]);
+       return (uint16_t)((p[0] << 8) | p[1]);
 }

 static __inline uint16_t __unused
@@ -216,7 +216,7 @@
 {
        const uint8_t *p = (const uint8_t *)buf;

-       return ((p[1] << 8) | p[0]);
+       return (uint16_t)((p[1] << 8) | p[0]);
 }

 static __inline void __unused
@@ -224,10 +224,10 @@
 {
        uint8_t *p = (uint8_t *)buf;

-       p[0] = (u >> 24) & 0xff;
-       p[1] = (u >> 16) & 0xff;
-       p[2] = (u >> 8) & 0xff;
-       p[3] = u & 0xff;
+       p[0] = (uint8_t)((u >> 24) & 0xff);
+       p[1] = (uint8_t)((u >> 16) & 0xff);
+       p[2] = (uint8_t)((u >> 8) & 0xff);
+       p[3] = (uint8_t)(u & 0xff);
 }

 static __inline void __unused
@@ -235,10 +235,10 @@
 {
        uint8_t *p = (uint8_t *)buf;

-       p[0] = u & 0xff;
-       p[1] = (u >> 8) & 0xff;
-       p[2] = (u >> 16) & 0xff;
-       p[3] = (u >> 24) & 0xff;
+       p[0] = (uint8_t)(u & 0xff);
+       p[1] = (uint8_t)((u >> 8) & 0xff);
+       p[2] = (uint8_t)((u >> 16) & 0xff);
+       p[3] = (uint8_t)((u >> 24) & 0xff);
 }

 static __inline uint32_t __unused

>Release-Note:

>Audit-Trail:
From: Christos Zoulas <christos@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: PR/36668 CVS commit: src/sys/sys
Date: Fri, 20 Jul 2007 15:07:15 +0000 (UTC)

 Module Name:	src
 Committed By:	christos
 Date:		Fri Jul 20 15:07:15 UTC 2007

 Modified Files:
 	src/sys/sys: endian.h

 Log Message:
 PR/36668: Matthias Kretschmer: Silence lint -aa complaints about "may lose
 accuracy".


 To generate a diff of this commit:
 cvs rdiff -r1.25 -r1.26 src/sys/sys/endian.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: David Laight <david@l8s.co.uk>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/36668: bogus complaints about sys/endian.h code when running lint -aa
Date: Fri, 20 Jul 2007 16:50:26 +0100

 On Fri, Jul 20, 2007 at 09:05:00AM +0000, mccratch@gmx.net wrote:
 > >Number:         36668
 > >Category:       lib
 > >Synopsis:       bogus complaints about sys/endian.h code when running lint -aa
 > "lint -aa" complains about "may loose accuracy" for sys/endian.h.
 > This is no bug at all, just annoying when using lint -aa.

 > -       p[1] = u & 0xff;
 > +       p[1] = (uint8_t)(u & 0xff);

 There is a big problem with adding such casts, they can very easily
 hide other (bigger) problems with the source.
 Especially if applied to every place an implicit integer narrowing
 conversion happens.

 	David

 -- 
 David Laight: david@l8s.co.uk

From: Matthias Kretschmer <mccratch@gmx.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: lib/36668: bogus complaints about sys/endian.h code when running lint -aa
Date: Fri, 20 Jul 2007 22:50:31 +0200

 On Fri, Jul 20, 2007 at 03:55:02PM +0000, David Laight wrote:
 > From: David Laight <david@l8s.co.uk>
 >  > -       p[1] = u & 0xff;
 >  > +       p[1] = (uint8_t)(u & 0xff);
 >  
 >  There is a big problem with adding such casts, they can very easily
 >  hide other (bigger) problems with the source.
 >  Especially if applied to every place an implicit integer narrowing
 >  conversion happens.

 The meaning of the code doesn't change and I don't see where there are
 any problems with this code as it just does the right thing.  It's
 nothing more than that lint is unable to tell that "u & 0xff" will
 really be just 8-bits long.  Similiar for other parts of the code in
 endian.h.

 --
 Matthias Kretschmer

Responsible-Changed-From-To: lib-bug-people->rillig
Responsible-Changed-By: rillig@NetBSD.org
Responsible-Changed-When: Wed, 25 May 2022 23:31:24 +0000
Responsible-Changed-Why:
I'm taking it, my plan is to fix the wrong lint warning.


From: "Roland Illig" <rillig@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/36668 CVS commit: src/tests/usr.bin/xlint/lint1
Date: Thu, 26 May 2022 07:03:03 +0000

 Module Name:	src
 Committed By:	rillig
 Date:		Thu May 26 07:03:03 UTC 2022

 Modified Files:
 	src/tests/usr.bin/xlint/lint1: msg_132.c msg_132.exp

 Log Message:
 tests/lint: demonstrate wrong 'may lose accuracy' warning

 Reported in PR 36668, fixed in sys/sys/endian.h 1.26 from 2007-07-20,
 unfixed in sys/sys/endian.h 1.29 from 2014-03-18.


 To generate a diff of this commit:
 cvs rdiff -u -r1.9 -r1.10 src/tests/usr.bin/xlint/lint1/msg_132.c
 cvs rdiff -u -r1.8 -r1.9 src/tests/usr.bin/xlint/lint1/msg_132.exp

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Roland Illig" <rillig@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/36668 CVS commit: src
Date: Thu, 26 May 2022 09:26:00 +0000

 Module Name:	src
 Committed By:	rillig
 Date:		Thu May 26 09:26:00 UTC 2022

 Modified Files:
 	src/tests/usr.bin/xlint/lint1: msg_132.c msg_132.exp
 	src/usr.bin/xlint/lint1: tree.c

 Log Message:
 lint: do not warn about loss in accuracy if the actual value fits

 The expression 'any & 0xff' can always be assigned to 'uint8_t' without
 loss of any value bits.  In the same way, '(any & 0xff) << 8' can always
 be assigned to 'uint16_t'.

 Previously, lint warned about these cases.  Fix these wrong warnings by
 tracking the possible values of integer expressions across a single
 expression.

 Fixes PR 36668, so that <sys/endian.h> does not need to be cluttered
 with useless casts anymore.


 To generate a diff of this commit:
 cvs rdiff -u -r1.10 -r1.11 src/tests/usr.bin/xlint/lint1/msg_132.c
 cvs rdiff -u -r1.9 -r1.10 src/tests/usr.bin/xlint/lint1/msg_132.exp
 cvs rdiff -u -r1.443 -r1.444 src/usr.bin/xlint/lint1/tree.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: rillig@NetBSD.org
State-Changed-When: Thu, 26 May 2022 09:37:40 +0000
State-Changed-Why:
Fixed for NetBSD 10, thanks for the PR.


From: "Roland Illig" <rillig@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/36668 CVS commit: src
Date: Thu, 26 May 2022 20:17:40 +0000

 Module Name:	src
 Committed By:	rillig
 Date:		Thu May 26 20:17:40 UTC 2022

 Modified Files:
 	src/tests/usr.bin/xlint/lint1: msg_132.c msg_132.exp
 	src/usr.bin/xlint/lint1: tree.c

 Log Message:
 lint: do not warn about 'uint32_t = uint64_t >> 32'

 If all possible values fit into the destination type, there is no
 possibility of losing accuracy.

 Enhances PR 36668.


 To generate a diff of this commit:
 cvs rdiff -u -r1.12 -r1.13 src/tests/usr.bin/xlint/lint1/msg_132.c
 cvs rdiff -u -r1.11 -r1.12 src/tests/usr.bin/xlint/lint1/msg_132.exp
 cvs rdiff -u -r1.448 -r1.449 src/usr.bin/xlint/lint1/tree.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.