zfs + uma

[pluknet]

On 18 September 2010 17:52, Robert N. M. Watson <rwatson at freebsd.org> wrote:
>
> On 18 Sep 2010, at 13:35, Fabian Keil wrote:
>
>> Doesn't build for me on amd64:
>>
>> fk at r500 /usr/src/tools/tools/umastat $make
>> Warning: Object directory not changed from original /usr/src/tools/tools/umastat
>> cc -O2 -pipe  -fno-omit-frame-pointer -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c umastat.c
>> cc1: warnings being treated as errors
>> umastat.c: In function 'uma_print_bucketlist':
>> umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'uint64_t'
>> umastat.c:234: warning: format '%llu' expects type 'long long unsigned int', but argument 4 has type 'uint64_t'
>> umastat.c: In function 'uma_print_cache':
>> umastat.c:245: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'u_int64_t'
>> umastat.c:246: warning: format '%llu' expects type 'long long unsigned int', but argument 3 has type 'u_int64_t'
>> umastat.c: In function 'main':
>> umastat.c:416: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'u_int64_t'
>> umastat.c:418: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'u_int64_t'
>> umastat.c:420: warning: format '%llu' expects type 'long long unsigned int', but argument 2 has type 'u_int64_t'
>> umastat.c:426: warning: dereferencing type-punned pointer will break strict-aliasing rules
>> umastat.c:429: warning: dereferencing type-punned pointer will break strict-aliasing rules
>> *** Error code 1
>>
>> Stop in /usr/src/tools/tools/umastat.
>>
>> The attached patch seems to work around the problem, I'm not sure if
>> the casts to void* are better than decreasing the WARN level, though ...
>
> This is a 32-bit/64-bit issue. Probably all pointers printing should be converted to %p, and large integer types to %ju and %jd, perhaps with a cast first to intmax_t or uintmax_t if required.
>

FYI, There is a PR 146119 about sort of fixing that issues.

-- 
wbr,
pluknet