31–40 of 74 posts
Why can't developers, y'know, ACTUALLY READ THE BLOODY WARNINGS? And then, y'know, they could FIX MORE THAN THE FIRST ONE after a single build pass?
We detached this subthread from https://news.ycombinator.com/item?id=12155394 and marked it off-topic.
> Enabling -Werror in distributions virtually guarantees that they won't build: Even if you took care of all compiler warnings in all compilers for which you enable this switch, it's just a question of time till a new compiler version comes along that has a new warning message and - BOOM. This is a feature. This triggers a review of the new warnings introduced by the new compiler version, to see if they have found bu…
The thing is, the software already had these bugs, and worked well enough for most people despite them, its not worth breaking the build over unless you are the developer.
I see the issue as: there are warnings and warnings One thing is for the compiler to warn about something like implicit conversion of one type to another. Another, very different, if warning for things that are correct but might be in error (like 'for' without brackets, etc)
PS: It's the same reason you capitalize the first letter in a sentence.
Earlier quoted context omitted.
And: #pragma GCC diagnostic push #pragma GCC diagnostic warning "-Wspecific-warning" #pragma GCC diagnostic ignored "-Wspecific-warning" ... #pragma GCC diagnostic pop For warnings you want to disable in a smaller scope. s/GCC/clang/ for clang. Bonus points: #define MM_WARNING_IGNORE_GCC(x) MM_IF_GCC( _Pragma(GCC diagnostic ignored x) ) #define MM_WARNING_IGNORE_CLANG(x) MM_IF_CLANG( _Pragma(clang diagnostic ignored…
clang understands #pragma GCC diagnostic fine, no need to have special code for it.
Why can't developers, y'know, ACTUALLY READ THE BLOODY WARNINGS? And then, y'know, they could FIX MORE THAN THE FIRST ONE after a single build pass?
In my observation, the problem is recompilation avoidance. If you miss it the first time around (maybe you're just trying to get the thing to run) they won't come back unless you do a full rebuild. With a little care you can build a build system that will print them out every time you run, but it takes some care.
I started programming in a world where you had to wait a day to get 300 lines of Fortran built. Now I routinely build the whole 44Gb of community ports of a major Linux distro in three days on a three hundred buck box at home.
There are 24 hours in a day, and your full rebuild will go just fine while you sleep, so long as you DON'T use -Werror.
Packagers don't need this information unless it will stop the software from functioning as it has previously been functioning (prexisting bugs included).
Go has the equivalent of -Werror on all the time. How does it address the issue of "your compiler might emit a warning that my compiler didn't?"
There's only 2 go compilers, there's like 20 c compilers
Earlier quoted context omitted.
In my observation, the problem is recompilation avoidance. If you miss it the first time around (maybe you're just trying to get the thing to run) they won't come back unless you do a full rebuild. With a little care you can build a build system that will print them out every time you run, but it takes some care.
Why avoid recompiling? Why this reluctance to do a full rebuild? I started programming in a world where you had to wait a day to get 300 lines of Fortran built. Now I routinely build the whole 44Gb of community ports of a major Linux distro in three days on a three hundred buck box at home. There are 24 hours in a day, and your full rebuild will go just fine while you sleep, so long as you DON'T use -Werror.
The shorter the feedback loop, the less context I have to rebuild for errors, the faster I can fix the error, the more efficient I am.
I'm not so far along that I make much use of the red squiggly lines generated by my IDE to highlight syntax errors before I even hit save - I use too many languages that can't be adequately parsed that fast for them to be terribly accurate - but it's a sign of just how much people want to shorten that feedback loop.
Have the CI server do full rebuilds overnight? Sure. Although I still have to bug my coworkers to pay enough attention to the CI server to even notice it's gone red from their changes, at times. Convincing them to read through the warning logs is a nonstarter.
Earlier quoted context omitted.
Go has something of an imposed rigidity that a lot of C programmers I think wouldn't tolerate well (culturally, viscerally),- one example: the whole comment out all unused variables because you commented out a function for debugging purposes during development (couldn't just pass a flag to the compiler, at least last time I used Go). Aside - I seem to remember a Blog post you wrote on your experience with the Go lang…
Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE.
> Commenting out code correctly, in a way that avoids complaints about unused code, should be possible to do in a proper IDE.
First of all, failing to compile, in an of itself should be reserved to a particular class of failures not to linting, I feel pretty strongly about this and I think a lot of other people do.
Further, I would say, that the complexity of an IDE that supports this - e.g. suppose you previously declared `uin64_t a, b, c, d;` and someone commented out the only function which uses c ? The editor should than make a new line with `//uint64_t c;` and than contract the old line correctly. That isn't a simple procedure to be sure and it's perfectly reasonable to use nano/vi to write code (you might say it's not effective) but at least in my opinion programtically correct code shouldn't fail because I'm not using super-advanced-ide-X.
[0] Aside - I tend to dislike this down-vote on disagree trend lately, imho the discussion would benefit from respecting and responding to disagreeable opinions and downvotes should be reserved for where (exclusively, but I guess subjectively - the comment isn't/worth the time effort to disagree or respond to e.g. blatant spam, highly condescending, personal attacks etc.)