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

[bugzilla-noreply at freebsd.org]

Mark Millard <markmi at dsl-only.net> has reassigned Bugzilla Automation
<bugzilla at FreeBSD.org>'s request for maintainer-feedback to pkg at 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 parameter
of type 'long' which may cause truncation of value
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210831



--- Description ---
src/utils.c has the code:

	bytes_change = 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=cortex_a7 specified) that reported this suggested
use of llabs (from C99).

The labs parameter and return type need not match size_t well for the purpose,
even ignoring unsigned vs. signed issue for the same width if that occurs.

	bytes_change = (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, &newsize,
. . .) 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 types
involved here do exist) then an explicit expansion of an expression (or macros
that expand to such) would be a way to get that more auto-adjusting nature:

	bytes_change = (size_t) ((oldsize <= newsize)
				 ?newsize - oldsize :oldsize-newsize);