Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Aug 2010 19:46:42 +1000 (EST)
From:      Bruce Evans <brde@optusnet.com.au>
To:        mdf@FreeBSD.org
Cc:        freebsd-arch@FreeBSD.org
Subject:   Re: RFC: replace vm_offset_t with uintptr_t and vm_size_t with size_t
Message-ID:  <20100813191149.V12776@delplex.bde.org>
In-Reply-To: <AANLkTik_2pXA1LP9dq-iOLkFrQBG7jP=4yUXBjtDOBF3@mail.gmail.com>
References:  <AANLkTik_2pXA1LP9dq-iOLkFrQBG7jP=4yUXBjtDOBF3@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 12 Aug 2010 mdf@FreeBSD.org wrote:

> Looking over the arch-specific definitions, using uintptr_t and size_t
> would not affect the actual width of these sizes.  However, it would
> simplify e.g. conformant printf(9) statements, since there is an
> approved specifier for size_t and, while there isn't one for
> uintptr_t, ptrdiff_t is pretty close (Bruce, is there a better
> specifier)?
>
> Admittedly, this isn't the simplest of undertakings, as there are 590
> instances of vm_size_t in the FreeBSD source code and 3887 of
> vm_offset_t.
>
> Has this proposal made the rounds before and been shot down for some reason?

Ugh, typedefs exist to avoid hard-coding assumptions like this.
Conformant printfs can't print any typedefed type except for ones with
their own format letter (like size_t) without upcasting to a standard
type.  This is painful, but that is how typedefs work and printf doesn't
work.  Simplifying printing of things shouldn't be allowed to mess up
the choice of types, especially in the kernel.

When I looked at this for vm_offset_t, it didn't seem to cause many
problems because most vm_offset_t's were printed using %x, and MD code
can reasonably assume that vm_offset_t is u_int.  Except it is u_long
on 64-bit arches...

I prefer to fix printf.  There should be a %I format something like in
sfio.  Unfortunately C99 only standardized the PRI* mistake.  I never
learned exactly what %I does, but think it should have 2 variations,
something like a plain %I causing the compiler to rewrite the literal
format string, replacing %I with the appropriate Standard format, and
%I<width> for interpretation by the library.  -Wformat has done all the
work needed to determine the correct replacement for 10-20 years.  So
vm_offset's and size_t's would normally be printed using "%I[xu]" (no
need for %z), but in message catalogues they would be printed using

     ("...%I*[xu] %I*[xu]...", ...
     sizeof(vm_offset_t) * CHAR_BIT, var_of_type_vm_offset_t,
     sizeof(size_t) * CHAR_BIT,  var_of_type_vm_offset_t, ...)

Except that came out too painful (almost as bad as using PRI*).  I
think I would usually avoid using %I<width> if it were as messy as
this, and use %j and require all integer args to be of type [u]intmax_t.

%I could also be a more global directive (either at the front of every
literal format string that wants rewriting for all args, or in CFLAGS
for all strings in a file).

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100813191149.V12776>