Announcement

Collapse
No announcement yet.

Linux 5.15 Enabling "-Werror" By Default For All Kernel Builds

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • gigi
    replied
    well... well.. linus is looking out for errors on his branch for a quite sometime and probably notoiced or better irked with simple or medium issues which can be fixed before sending patches.

    lets see how this will effect devs and the developnent process of kernel itself.

    Leave a comment:


  • anarki2
    replied
    It's surprising it hasn't been a case until now. OpenSSL has been doing this for ages.

    Leave a comment:


  • L_A_G
    replied
    Well considering most of Linus' legendary rants have been about code quality this is at the very least tonally consistent with the guy.

    I also wouldn't be the least bit surprised if this is primarily aimed at graphics driver devs as they are pretty infamous for their nonchalant attitude towards code quality and even serious warnings thrown up by compilers.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by set135
    This does not change the bar for code getting in. This is only for robots who otherwise might not flag warnings. Linus has never tolerated warnings and if you ask him to pull code that outputs warnings he will likely not accept it. He also hates useless warnings and patches that do nothing useful except shut them up. So, either the warning is helpful and the code is fixed, or it's useless and shut off.
    This is not quite right. Linus of the lInux kernel when a warning is in fact useless to disable it usage a bug report has to be submitted to the compiler developer and be confirmed that this is a bug even with this its not sure that the warning test will be turned off globally.



    There are few examples in the Linux kernel
    #pragma GCC diagnostic ignored "-Wsuggest-attribute=format"
    this has only been required 10 times across the complete kernel. This has a fairly good success rate of being 1000 to 1 yes over 10000 faults were found when that was first turned on only 10 were in fact errors.

    Best practise is really to leave as many compiler error detections on as you can and tag out the areas that those features don't work.

    Linus will accept patches that disable invalid warnings from being displayed he will be demanding you have confirmation from the compiler developer before submit the patch or he will have your head.

    Leave a comment:


  • oiaohm
    replied
    Originally posted by NobodyXu View Post
    Linux kernel doesn’t use standard IO functions provided by C stdio.h, so this option likely do nothing.
    "-Werror=format-security" does not require you to use C stdio.h for it to be useful.



    Code:
    extern int my_printf (void *my_object, const char *my_format, ...) __attribute__ ((format (printf, 2, 3)));
    The fun of the format attribute. You can name your printf/scanf functions what ever you like as long as you include attribute that gcc/clang knows what the it is.




    Yes surprise its already declared all over the place around the Linux kernel. So yes -Werror=format-security if you do turn it on with the Linux kernel it really does something.

    Leave a comment:


  • indepe
    replied
    Originally posted by coder View Post
    Depends on what you mean by "all warnings". Some developers tend to be fairly aggressive, in terms of which they enable.
    When I wrote "all" I meant all those that are enabled. I do have a lot enabled (most notable exception is "unused parameters"), but not all those that need to be enabled individually.

    Originally posted by coder View Post
    Unfortunately, the more advanced warnings tend to be less reliable, which becomes problematic when someone decides to enact a -Werror policy.

    I've seen significant amounts of time wasted, and bugs actually getting introduced, in the course of fixing false-positive warnings (i.e. those which didn't indicate any real problem). In many instances, the resulting code is worse, in terms of being less readable or maintainable. I would argue that most of these warnings shouldn't even have been enabled.
    For example for which warnings? Maybe that comes with using a lot of external/legacy source code or include files that were written with a lot of warnings disabled?

    Leave a comment:


  • Serafean
    replied
    Create a combination matrix of supported architectures/compilers.
    It grows really fast. Werror prevented me from doing stupid things like assuming int size, or relying on arch specific overflow behaviour (BE/LE differences).
    Imagine writing a new driver, testing it on amd64, works fine. Then somebody tries running it on a Big endian MIPS machine. What happens can be very, very surprising... these compiler warnings/errors help catch *a lot* of the low hanging fruit.

    Leave a comment:


  • okias
    replied
    Originally posted by coder View Post
    Depends on what you mean by "all warnings". Some developers tend to be fairly aggressive, in terms of which they enable. Unfortunately, the more advanced warnings tend to be less reliable, which becomes problematic when someone decides to enact a -Werror policy.

    I've seen significant amounts of time wasted, and bugs actually getting introduced, in the course of fixing false-positive warnings (i.e. those which didn't indicate any real problem). In many instances, the resulting code is worse, in terms of being less readable or maintainable. I would argue that most of these warnings shouldn't even have been enabled.

    I've also seen developers take the easy way out. Such as getting rid of unused variables holding return code values, rather than actually checking them and handling errors appropriately. But hey, the warning count was reduced, so the code must be better!
    Well, let's assume that with newer gcc/llvm, there is less and less false positives. Just having clean log and seeing new warnings which will appear (not talking about -Werror) is beneficial.

    I tried write patch for many projects, where build system prints warning after warning and in the end, I couldn't even quickly see from build log if my code introduced any new warnings...

    Yes, you can create wrong fixes, but I believe review process for Linux kernel is good enough to catch these wrong solutions before they go in.

    Leave a comment:


  • perpetually high
    replied
    Originally posted by brad0 View Post

    That is very evident.
    Really? What did I say that was very stupid? I'm being serious. I don't want to look stupid on national TV again. Tell me.

    Leave a comment:


  • user556
    replied
    I had a situation recently that surprised me at the time. The architecture I work on has 512 general purpose registers and the ability to address them like RAM. Not too surprisingly, the C compiler doesn't have any recognition of using pointers in this manner. It could auto allocate a variable to a register but all my attempts to define or reassign a pointer to general register space either got warnings or errors.

    In the end I used inline assembly to eliminate any confusion.

    Leave a comment:

Working...
X