On Mon, Jan 21, 2013 at 9:10 PM, Markus Armbruster <arm...@redhat.com> wrote: > Blue Swirl <blauwir...@gmail.com> writes: > >> On Mon, Jan 21, 2013 at 10:36 AM, Markus Armbruster <arm...@redhat.com> >> wrote: >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> On 20 January 2013 15:54, Blue Swirl <blauwir...@gmail.com> wrote: >>> [...] >>>> I don't think there's much point adding tons of "XXX" comments >>>> when a bunch of these aren't actually wrong code. >>> >>> Moreover, such comments make them look intentional to static analyzers. >>> I doubt lying to our tools is a good idea. >> >> I see. That was not my intention. > > I figured that much :) > >>>> If you want to fix >>>> this I think a better approach would be more focused patches aimed >>>> at adding 'break;' or "/* fallthrough */" based on actual human >>>> examination of the surrounding code. >>> >>> Indeed. I'd gladly provide a list of fall throughs Coverity dislikes. >>> >>> Additionally, I'd suggest to enforce a suitable convention for new code. >>> I find this one sensible: either "break;" or "/* fall through */" is >>> required, except right after a case label, a goto, continue, or return >>> statement, or function call that never returns. >> >> When Clang implements for example an attribute that can be used in C, >> we could add a Clang specific macro. Then all fall through comments >> could be replaced with this macro. > > If I was working on Clang, I wouldn't bother. Instead, assume a fall > through is intentional when there's a comment. Unlike attributes, the > comments are already there, and other static checkers already work that > way.
At least __fallthrough and __builtin_fallthrough() were mentioned here: http://clang-developers.42468.n3.nabble.com/should-Wimplicit-fallthrough-require-C-11-td4028144.html
