svn commit: r231669 - head/sys/fs/tmpfs

[Bruce Evans]

On Tue, 14 Feb 2012, Tijl Coosemans wrote:

> On Tuesday 14 February 2012 12:24:24 Tijl Coosemans wrote:
>> Log:
>>   Replace PRIdMAX with "jd" in a printf call. Cast the corresponding value to
>>   intmax_t instead of uintmax_t, because the original type is off_t.
>
> There should really be a better way to print 64 bit numbers than (ab)using
> intmax_t. I'm sort of interested in adding an int128_t type and that would
> make intmax_t 128 bit.

off_t isn't necessarily a 64-bit number.  It needs to be 65 bits just to
work without hacks for /dev/kmem on 64-bit machines.  It might use your
128-bit type for that :-).  This would be too wasteful for just that of
course.

The right way to print N-bit numbers is %I[AaeEFgGxX], where the
compiler replaces %I in the string literal by the correct format for
the arg (this might be %d, %u, %ld, ..., %ju, %f) instead of complaining
that the format doesn't match the arg.  Hex formats need and floating
point formats other than %f need an extra letter.  Floating point
variadic args can only be double or long double IIRC, so %I is less
needed for them (it lets the compiler handle the 'L's that specify
long doubles).  Field widths and precisions that separate the % from
the I don't effect the meaning of the I.

This only works if the types can be checked at compile time.  Message
catalogues can have more limited simplifications which I haven't thought
about much.  Language extensions that are not as standard as -Wformat
seem to be needed even to detect type mismatches.  Once they are
detected, they can be fixed up by rewriting the format non-literal.
The compiler can help a bit by rewriting the initial string literal
and subsequent args in a form that is easier to rewrite.

Bruce