On Mon, Sep 02, 2013 at 06:52:45PM -0700, Joe Perches wrote: > On Mon, 2013-09-02 at 18:34 -0700, Josh Triplett wrote: > > I'd suggest a couple more, which > > *should* always make sense, and to the best of my knowledge don't tend > > to generate false positives: > > > > C99_COMMENTS > > I don't have a problem with c99 comments. > As far as I know, Linus doesn't either. > > https://lkml.org/lkml/2012/4/16/473
That doesn't look like an endorsement so much as a statement that C99 comments are less awful than the net/ special-case comment style. Documentation/CodingStyle chapter 8 says: > Linux style for comments is the C89 "/* ... */" style. > Don't use C99-style "// ..." comments. If that no longer holds true, we should remove it from CodingStyle. As far as I know, though, it still holds. In any case, it rarely comes up; most kernel code doesn't use such comments. > > CONFIG_EXPERIMENTAL > > CVS_KEYWORD > > OK, but <shrug> Sure, I don't expect them to come up often. > > ELSE_AFTER_BRACE > > I wouldn't do this one. I think > there are some false positives here. Oh? What kinds of false positives have you seen? In any case, fair enough. > > GLOBAL_INITIALIZERS > > INITIALISED_STATIC > > Nor these. I don't see an obvious way for those to have false positives. What have you seen? > > INVALID_UTF8 > > LINUX_VERSION_CODE > > MISSING_EOF_NEWLINE > > OK I suppose. Not particularly critical, but uncontroversial and no false positives. > > PREFER_SEQ_PUTS > > PRINTK_WITHOUT_KERN_LEVEL > > There are a lot of these. > I suggest no here. I assume the bot only applies this to new patches, not to existing code, in which case these seem completely reasonable. New code should follow these, even if we don't mass-fix existing code. > > RETURN_PARENTHESES > > SIZEOF_PARENTHESIS > > It's in coding style, but some newish patches > do avoid them. It's a question about how noisy > you want your robot to be. These two seem reasonable to enforce on new code. I agree that they shouldn't trigger mass cleanups of existing code. > > SPACE_BEFORE_TAB > > TRAILING_SEMICOLON > > TRAILING_WHITESPACE > > USE_DEVICE_INITCALL I didn't see any comment from you on these four. Thoughts? > > USE_RELATIVE_PATH > > Having checkpatch tell people how to write changelogs > I think not a great idea. In general, sure, but that particular one seems OK. In any case, not particularly critical. > > These *ought* to make sense, but I don't know their false positive rates: > > > > HEXADECIMAL_BOOLEAN_TEST > > That's a good one. 0 false positives. Ah, good. > > ALLOC_ARRAY_ARGS > > Yes, this would be reasonable too. Excellent. > > CONSIDER_KSTRTO > > I think orobably not. This would be a cleanup thing. Even if applied to new code only? New code should use the right functions to start with. > > CONST_STRUCT > > OK Good to know; glad to hear it doesn't have false positives. > > SPLIT_STRING > > I suggest no but <shrug> I can easily believe that it has too many false positives. Let's leave that one alone for now. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
