On Wed, Nov 2, 2011 at 4:56 PM, Alexander Best <arun...@freebsd.org> wrote:
> i sent the following message to freebsd-quaestions@ and got no answer. mybe it
> is better suited for freebsd-hackers@.
>
> 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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
