From owner-freebsd-pkg@freebsd.org Tue Jul 5 01:36:54 2016 Return-Path: Delivered-To: freebsd-pkg@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 68D70B90DE6 for ; Tue, 5 Jul 2016 01:36:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5231728D7 for ; Tue, 5 Jul 2016 01:36:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 5188BB90DE5; Tue, 5 Jul 2016 01:36:54 +0000 (UTC) Delivered-To: pkg@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 512B0B90DE4 for ; Tue, 5 Jul 2016 01:36:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 268B628D5 for ; Tue, 5 Jul 2016 01:36:54 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u651asRK047774 for ; Tue, 5 Jul 2016 01:36:54 GMT (envelope-from bugzilla-noreply@freebsd.org) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" From: bugzilla-noreply@freebsd.org To: pkg@FreeBSD.org Subject: maintainer-feedback requested: [Bug 210831] ports-mgmt/pkg 1.8.6: src/utils.c in 32-bit context like armv6/powerpc: 'labs' given an argument of type 'long long' but has parameter of type 'long' which may cause truncation of value Date: Tue, 05 Jul 2016 01:36:54 +0000 X-Bugzilla-Type: request X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: pkg@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? Message-ID: In-Reply-To: References: X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-pkg@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Binary package management and package tools discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 01:36:54 -0000 Mark Millard has reassigned Bugzilla Automation 's request for maintainer-feedback to pkg@FreeBSD.org: Bug 210831: ports-mgmt/pkg 1.8.6: src/utils.c in 32-bit context like armv6/powerpc: 'labs' given an argument of type 'long long' but has paramet= er of type 'long' which may cause truncation of value https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D210831 --- Description --- src/utils.c has the code: bytes_change =3D labs(newsize - oldsize); where newsize and oldsize have type int64_t (or what it translates to) and bytes_changed has type size_t (or what it translates to). The compiler targeting armv6 (with -mcpu=3Dcortex_a7 specified) that reported this sugge= sted use of llabs (from C99). The labs parameter and return type need not match size_t well for the purpo= se, even ignoring unsigned vs. signed issue for the same width if that occurs. bytes_change =3D (size_t) llabs(newsize - oldsize); likely would be more auto adjusting without compiler warnings for current contexts. [Depends on what set_pkg_jobs_summary_pkg(. . ., &oldsize, &newsi= ze, . . .) is doing under the variations in types for various contexts. Likely oldsize and newsize values do track size_t or a signed variant with the same width to an extent.] If prior to C99 is to be covered (where llabs might not exist even if the t= ypes involved here do exist) then an explicit expansion of an expression (or mac= ros that expand to such) would be a way to get that more auto-adjusting nature: bytes_change =3D (size_t) ((oldsize <=3D newsize) ?newsize - oldsize :oldsize-newsize);