RFC: replace vm_offset_t with uintptr_t and vm_size_t with
size_t
Bakul Shah
bakul at bitblocks.com
Sun Aug 15 16:45:47 UTC 2010
On Fri, 13 Aug 2010 19:46:42 +1000 Bruce Evans <brde at optusnet.com.au> wrote:
>
> 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).
Have you looked at plan9's fmtinstall(3)? Basically
fmtinstall('x', foo) will install function foo to be called
when %...x is seen in a format string. foo takes struct Fmt*
which points to stuff needed for formatting. Things like
width, precision, flags, whether output buffer is runes or
chars etc. Once you install the formats you need, their use
becomes pretty painless. Perhaps kernel's printf can be
extended (or rebuilt) using this idea? Seems to me something
like that would be better and much more extensible than
inflicting %I*[xu]. This does not require compiler magic but
you also lose the -Wformat crutch.
More information about the freebsd-arch
mailing list