svn commit: r291741 - head/sys/geom

[Bruce Evans]

On Fri, 4 Dec 2015, Andrew Turner wrote:

> On Fri, 4 Dec 2015 23:42:51 +1100 (EST)
> Bruce Evans <brde at optusnet.com.au> wrote:
> ...
>> This looks like 5 style bugs and 0 issues:
>>
>> 3 old style bugs:
>> - use of bool
>
> I don't seem to see where in style(9) we disallow the use of bool. Can
> you point me where this is specified?

This is specified by not giving an example of using it.  style(9) was
mostly written 10+ years before bool existed, and bool is so
(un)important that style(9) wasn't changed to allow it in its 16+
years of existence.

This is also a style bug since it was not used anywhere in nearby code,
but nearby code used the older boolean_t.  I don't mind using bool in
new code.

I typedefed everything too much in code that I wrote 25-30 years ago.

For C99 types more useful than bool, but leading to a deeper morasse,
use [u]int_fastN_t and [u]int_leastN_t types in <stdint.h>.  These are
so useable that they are used approximately 0 times in the kernel and
10 times in userland (perhaps more than 10 in contrib).  But they
should almost always be used where fixed-width types are now used.
E.g., using uint16_t asks for a type of width exactly 16 bits at all
costs.  The costs are:
- this type might not be supported.  Then nothing would work.  But
   uint_least16_t should always be supported, and anything that doesn't
   need precisely 16 bits would work using it.  It only needs to be
   larger than 16 bits, so it can be u_int.
- this type might be supported, but might be much slower than
   uint_fast16_t.  This is probably the case on arches like old alpha
   where the hardware only does wider or narrower memory accesses so
   has do loads and stores of different sizes and repack
- this type might be supported, but might be slower than uint_fast16_t.
   This is the case on arches like old i386 where movz was slow and
   instruction fetch bandwidth was also inadquate (so the extra movz's
   were even slower)
- this type might be supported, but might be a little slower than
   uint_fast16_t.  This was the case on arches like current x86.
   Extra movz instructions are still required, but these excecute fast
   on current x86.

Kernel code needs fixed-width types in many places in hardware and network
storage layouts.

Fixed-width types are also useful for saving space in software storage
layouts.  But they are just logically wrong for that.  The
[u]int_leastN_t are logically right for that.  But in practice, all
the optional [u]intN_t types exist the [u]int_leastN_t types are not
needed.  Using either leads to a type morasses so is rarely done.  It
is never done in the kernel.

Fixed-width types should not be used except for storage.  They should
not be part of ABIs except (quite often) to force a specific ABI (in
this case, only "fast" fixed-width types should be used in the ABI,
but then the ABI won't be optimal forever).  They should be converted
to "fast" types when they are loaded and not converted back until they
are stored to non-temporary variables.  This leads to type morasses
so is rarely done.  It is never done in the kernel.

Before <stdint.h> existed, the kernel hard-coded uint8_t as u_char,
etc.  The 8-bit cases of this are now standard (u_char must be uint8_t
on newer POSIX).  The kernel now uses fixed-width types excessively.
Not only in storage layouts, but also for function calls and local
variables using types copied from the storage structs.  Fixed-width
instead of "fast" integer types are also pessimal for function calls.
Inlining of functions reduces this pessimization.

Bruce