On 14.03.2024 00:04, Stefano Stabellini wrote: > On Wed, 13 Mar 2024, Jan Beulich wrote: >> On 13.03.2024 01:28, Stefano Stabellini wrote: >>> + Switch statements with integer types as controlling expression >>> + should have a default label: >>> + >>> + - if the switch is expected to handle all possible cases >>> + explicitly, then a default label shall be added to handle >>> + unexpected error conditions, using BUG(), ASSERT(), WARN(), >>> + domain_crash(), or other appropriate methods; >>> + >>> + - if the switch is expected to handle a subset of all >>> + possible cases, then a default label shall be added with an >>> + in-code comment as follows:: >>> + >>> + /* only handle a subset of the possible cases */ >>> + default: >>> + break; >> >> Unless it being made crystal clear that mechanically reproducing this >> comment isn't going to do, I'm going to have a hard time picking >> between actively vetoing or just accepting if someone else acks this. >> At the very least, though, the suggested (or, as requested, example) >> comment should match ./CODING_STYLE. And it may need placing >> differently if I understood correctly what Misra / Eclair demand >> (between default: and break; rather than ahead of both). >> >> The only place I'd accept a pre-cooked comment is to cover the >> "notifier pattern". > > Hi Jan, > > During the MISRA C call we discussed two distinct situations: > > 1) when the default is not supposed to happen (it could be an BUG_ON) > 2) when we only handle a subset of cases on purpose > > For 2), it is useful to have a comment to clarify that we are dealing > with 2) instead of 1). It is not a pre-cooked comment. The comment > should be reviewed and checked that it is actually true that for this > specific switch the default is expected and we should do nothing. > > However, the comment is indeed pre-cooked in the sense that we don't > need to have several different variations of them to explain why we only > handle a subset of cases. > > The majority of people on the call agreed with this (or so I understood).
Hmm, my -0.5 was on the understanding that we would not encourage entirely mechanical adding of such comments. Yet providing a pre-worded comment here does exactly this, in my opinion. Imo here it should be made clear _where_ the comment needs to be put, but not how it is to be worded. As was (largely) settled on during the discussion, the comment doesn't need to go into a great level of detail. Jan
