[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]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210831

            Bug ID: 210831
           Summary: 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
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: pkg at FreeBSD.org
          Reporter: markmi at dsl-only.net
             Flags: maintainer-feedback?(pkg at FreeBSD.org)
          Assignee: pkg at FreeBSD.org

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);

-- 
You are receiving this mail because:
You are the assignee for the bug.