question regarding style(9) and field initialisers in structs

mdf at FreeBSD.org mdf at FreeBSD.org
Thu Nov 3 00:42:48 UTC 2011


On Wed, Nov 2, 2011 at 4:56 PM, Alexander Best <arundel at freebsd.org> wrote:
> i sent the following message to freebsd-quaestions@ and got no answer. mybe it
> is better suited for freebsd-hackers at .
>
> hi there,
>
> i found hundreds of the following cases in the FreeBSD src:
>
> [...]
> struct periph_driver {
>        periph_init_func_t      init;
>        char                    *driver_name;
>        TAILQ_HEAD(,cam_periph) units;
>        u_int                   generation;
>        u_int                   flags;
>        #define CAM_PERIPH_DRV_EARLY    0x01
> };
> [...]
> static struct periph_driver dadriver =
> {
>        dainit, "da",
>        TAILQ_HEAD_INITIALIZER(dadriver.units), /* generation */ 0
> };
>
> ...is it proper programming practice to forget about the last field, if it
> would have been initialised to 0?

It's more likely that, in this instance, the field was added after the
initializer.  Without named initializers, all fields until the last
non-zero one need to be explicitly present.

style(9) doesn't address it, having been written too long ago, but IMO
initializations in a C translation unit [1] should use C99's named
initializer feature, to protect against future member re-ordering.
And it would be style(9) compliant to leave out any field whose
initial value is zero (though sometimes it's good to list it anyways
to make it clear that 0 was the desired value).

[1] Note that C++ doesn't support C99's named initializer syntax (even
in C++0x, which is a bit silly), so any struct initializers in a
header file like <sys/malloc.h> must use old-style, since FreeBSD
should continue to support writing kernel modules in C++.

Cheers,
matthew


More information about the freebsd-hackers mailing list