> And I'd rather keep the library warning free instead of telling the users to switch warnings off.
Thank you! Separately, but related: fuck you, Google! (every time I have to deal with protobuf in C++, I curse Google and their "we don't give a shit about signed vs unsigned comparisons").
And I don't think there's an excuse not to. I work on giant projects with tons of people, that still manage to use -Werror.
Yeah, some warnings are turned off, but not as many as you'd think, and usually for good reasons, which also includes deliberate design decisions. For example, we don't care about pre-C11 compatibility (because we won't build for pre-C11), so that warning is off. We also like 0-sized arrays, so that warning is off as well.
It's a moving target, because compiler engineers add new warnings over time. Adapting the new compiler means taking care of the new warnings. There's almost always a way to do so instead of turning a new warning off.
I don't understand this discussion. What I said was that for our big projects internally, we keep them warning-free, and -Werror obviously helps tremendously with that. Nobody said you need to ship externally with -Werror, or anything about external libraries the project may be using.
By keeping your own project warning-free in your environment, you are doing a service to everyone.
Sounds like you are doing the right thing (-Werror internally, not externally). So this discussion is probably just based on a miscommunication. Happens pretty often on HN unfortunately.
The problem is: it's infectious into the generated code, as well. Is that 3rd party or not? Yes, it was generated by a 3rd party tool, but from, ostensibly, _your_ protobuf file.
edit to add: and yes `-isystem` is absolutely a useful tool. If memory serves, though, it doesn't protect from macro or template expansions, though.
Thank you! Separately, but related: fuck you, Google! (every time I have to deal with protobuf in C++, I curse Google and their "we don't give a shit about signed vs unsigned comparisons").