On Fri, Oct 17, 2025 at 1:15 PM Ilya Maximets <[email protected]> wrote:
> 'default-const-init-field-unsafe' warning complains about allocating > structures on stack if they have any const fields. We use this for > classifier rules that are embedded into many other structures: > > ofproto/ofproto.c:4980:26: > error: default initialization of an object of type > 'struct rule_criteria' with const member leaves the > object uninitialized [-Werror,-Wdefault-const-init-field-unsafe] > 4980 | struct rule_criteria criteria; > | ^ > ./lib/classifier.h:356:15: > note: member 'priority' declared 'const' here > 356 | const int priority; > | ^ > > Priority is marked as const as it is not supposed to be changed after > the rule creation, as that would break the classifier logic. Any code > that changes the value is clearly seen, as it requires the explicit > CONST_CAST. Initialization functions are the only places where this is > happening. And these functions are always called for all the instances > allocated on stack, but clang fails to recognize this. > > I believe, described code pattern is useful, so it's better to turn > off the warning instead of making the field non-const. Alternative > would be to use an explicit initializer for every stack allocation > to silence the warning, but it feels like a bit too much. > > Signed-off-by: Ilya Maximets <[email protected]> > --- > I agree that this design pattern is worth retaining. Acked-by: Mike Pattrick <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
