svn commit: r211221 - head/usr.sbin/acpi/acpidump
brde at optusnet.com.au
Fri Aug 13 14:35:22 UTC 2010
On Fri, 13 Aug 2010, [utf-8] Dag-Erling SmÃ¸rgrav wrote:
> Bruce Evans <brde at optusnet.com.au> writes:
>> - `platform_class' has type uint16_t. u_int is larger than that on all
>> supported machines, and also on unsupported ones with 16-31 bit u_ints.
>> Thus the cast has almost no effect, and has no effect on the result.
> you have to cast it to *something*, unless you're willing to assume
> blindly that uint16_t == unsigned short (and use %h).
No, all function parameters are converted to *something*, and as I partly
explained above, the default something is always int or u_int, with the
lofical sign error for the int not causing any problems. Various cases:
- K&R compiler, or C90-C99 compiler with no prototype in scope: integer
parameters are converted to int or u_int if they are smaller than that
to start, else they are not converted.
- variadic function for a parameter after `...': same as for K&R.
- %h format for printf: makes little or no difference except for bogus
parameters. The parameter must end up as int or u_int after the default
promotion. The %h causes the parameter to be downcast to short or u_short.
This is different from taking a short or u_short parameter. You just
can't pass a short or a u_short to a variadic function,
Here uint16_t is converted to u_int on machines with 16-bit ints, else it
is converted to int.
>> Anyway, almost all typedefed types should be cast to [u]intmax_t for
>> printing, so that you don't have to know too much about what they are.
> long or even int is fine in many cases, e.g. uid_t, mode_t
Though it works now, it might break someday. 32-bit ino_t and printing
it with %u should have broken already.
More information about the svn-src-head