Date: Sat, 5 Dec 2015 05:03:25 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andrew Turner <andrew@fubar.geek.nz> Cc: Bryan Drewery <bdrewery@freebsd.org>, "Kenneth D. Merry" <ken@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r291741 - head/sys/geom Message-ID: <20151205031713.T3286@besplex.bde.org> In-Reply-To: <20151204125355.6712d782@bender> References: <201512040338.tB43cZY1053263@repo.freebsd.org> <56610B6B.8010708@FreeBSD.org> <20151204233052.J2220@besplex.bde.org> <20151204125355.6712d782@bender>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 4 Dec 2015, Andrew Turner wrote: > On Fri, 4 Dec 2015 23:42:51 +1100 (EST) > Bruce Evans <brde@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151205031713.T3286>