3 ms·

I'd argue that if you used -Wall and you got all the warnings you can't really complain too much because you got exactly what you asked for.

by zik 7y ago

greglindahl 7y ago
That's fine for an argument in a bar, and not so helpful for people who are doing software engineering with code that is developed under multiple compiler versions. Or who build old code versions with a new compiler version.
- reitzensteinm 7y ago
  Why are "people who are doing software engineering" expecting to build code in a new compiler without migration effort, and ignoring new warnings that have been added potentially pointing to existing undetected issues just so the code continues to compile? "People who want to get shit done", sure. Pragmatists, even.
- monadgonad 7y ago
  It's only not so helpful because -Wall is badly named and now we're forced to deal with that legacy. Ideally, -Wall would be the same as clang's -Weverything, and there'd be a -Wstandard (or something) flag for what -Wall currently does.
- flukus 7y ago
  How often do you get warnings that aren't either real bugs or trivial to fix anyway? The problem with ignoring warnings is that they tend to accumulate and before long you can't see the ones you really do need to pay attention to. And yes that means you have to take the time to cleanup on new compilers with more warnings.
tom_mellior 7y ago
The issue really isn't with -Wall, it's with -Werror. If I release an open source package that compiles fine today with -Wall -Werror, and tomorrow there's a new compiler release that adds a new warning to -Wall, then that adds a new error to my package, and users trying to compile it with a new compiler will fail and complain. They didn't ask for -Wall -Werror, they only asked for some program that produces a working executable with ./configure ; make. Like enabling assertions or not, this is (a matter of opinion, and) a difference between "development" and "release" compilations. Ideally we would consistently use something like ./configure --devel for one and ./configure --release for the other. Other languages' build systems have this built in, and building a tarball with autotools used to do something similar, but if you just pull something off GitHub it's not clear what mode you'll end up with.
- thaumasiotes 7y ago
  > Ideally we would consistently use something like ./configure --devel for one and ./configure --release for the other. Other languages' build systems have this built in Makefile has this built in too; you'd just be saying "make development" instead of "make --development".
  - tom_mellior 7y ago
    If you need to write specific rules for it, I wouldn't call it "built in". But sure, it's possible. But there is no general consensus across projects to do it, and do it the same way.

I'd argue that if you used -Wall and you got all the warnings you can't really complain too much because you got exactly what you asked for.

by zik 7y ago

I'd argue that if you used -Wall and you got all the warnings you can't really complain too much because you got exactly what you asked for.

greglindahl 7y ago

That's fine for an argument in a bar, and not so helpful for people who are doing software engineering with code that is developed under multiple compiler versions. Or who build old code versions with a new compiler version.

reitzensteinm 7y ago
Why are "people who are doing software engineering" expecting to build code in a new compiler without migration effort, and ignoring new warnings that have been added potentially pointing to existing undetected issues just so the code continues to compile? "People who want to get shit done", sure. Pragmatists, even.
monadgonad 7y ago
It's only not so helpful because -Wall is badly named and now we're forced to deal with that legacy. Ideally, -Wall would be the same as clang's -Weverything, and there'd be a -Wstandard (or something) flag for what -Wall currently does.
flukus 7y ago
How often do you get warnings that aren't either real bugs or trivial to fix anyway? The problem with ignoring warnings is that they tend to accumulate and before long you can't see the ones you really do need to pay attention to. And yes that means you have to take the time to cleanup on new compilers with more warnings.

tom_mellior 7y ago

The issue really isn't with -Wall, it's with -Werror. If I release an open source package that compiles fine today with -Wall -Werror, and tomorrow there's a new compiler release that adds a new warning to -Wall, then that adds a new error to my package, and users trying to compile it with a new compiler will fail and complain. They didn't ask for -Wall -Werror, they only asked for some program that produces a working executable with ./configure ; make. Like enabling assertions or not, this is (a matter of opinion, and) a difference between "development" and "release" compilations. Ideally we would consistently use something like ./configure --devel for one and ./configure --release for the other. Other languages' build systems have this built in, and building a tarball with autotools used to do something similar, but if you just pull something off GitHub it's not clear what mode you'll end up with.

thaumasiotes 7y ago
> Ideally we would consistently use something like ./configure --devel for one and ./configure --release for the other. Other languages' build systems have this built in Makefile has this built in too; you'd just be saying "make development" instead of "make --development".
- tom_mellior 7y ago
  If you need to write specific rules for it, I wouldn't call it "built in". But sure, it's possible. But there is no general consensus across projects to do it, and do it the same way.