svn commit: r235822 - in head: sys/dev/esp sys/gnu/fs/xfs/FreeBSD usr.sbin/ppp usr.sbin/rpc.lockd

[Bruce Evans]

On Wed, 23 May 2012, Xin Li wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 05/23/12 07:56, Bjoern A. Zeeb wrote:
>>
>> On 23. May 2012, at 06:49 , Xin LI wrote:
>>
>>> Author: delphij Date: Wed May 23 06:49:50 2012 New Revision:
>>> 235822 URL: http://svn.freebsd.org/changeset/base/235822
>>>
>>> Log: Fix build:
>>>
>>> - Use %ll instead of %q for explicit long long casts; - Use %j
>>> instead of %q in XFS and cast to intmax_t.
>>>
>>> Tested with:	make universe
>>
>>
>> I am still seeing XLP64 failing to compile:
>>
>> cc1: warnings being treated as errors
>> /scratch2/tmp/bz/HEAD.svn/sys/geom/geom_flashmap.c: In function
>> 'g_flashmap_print':
>> /scratch2/tmp/bz/HEAD.svn/sys/geom/geom_flashmap.c:82: warning:
>> format '%08llx' expects type 'long long unsigned int', but argument
>> 2 has type 'off_t' [-Wformat]
>> /scratch2/tmp/bz/HEAD.svn/sys/geom/geom_flashmap.c:82: warning:
>> format '%08llx' expects type 'long long unsigned int', but argument
>> 3 has type 'off_t' [-Wformat]
>> /scratch2/tmp/bz/HEAD.svn/sys/geom/geom_flashmap.c:82: warning:
>> format '%llu' expects type 'long long unsigned int', but argument 5
>> has type 'off_t' [-Wformat]
>
> Weird, I don't know why I didn't caught this :-/  It seems that
> 'universe_kernel' does not do things after an existing universe build?

Well, new printf format errors/style bugs involving %ll have little to
do with old ones involving %q, even if they are not even style bugs but
fatal type mismatches.

> Should be fixed in r235849.

The following bugs remain:
- bogus types off_t for sl_start and sl_end.  The typedef for file offsets
   is very inappropriate for disk offsets.  But this seems to be a generic
   bug in geom.
- printing the signed type off_t using the unsigned formats %...x and
   %...u.  (The casts are to unsigned to match the formats.)
- printing sl_start and sl_end in hex format
- printing sl_start and sl_end in %08jx format:
   - this hex format doesn't even use '%#' or '0x%', so it is ambiguous
   - the output is not in tab format, so '08' is not needed to line it up
   - 08 doesn't even work for lining things up, except for 32-bit values.
     016 might work for 64-bit values.  But for general uint64_t values,
     there is no correct field width to use.

Bruce