On 2020/01/23 20:02:58, Dan Eble wrote: > On 2020/01/22 10:18:48, hanwenn wrote: > > alternately, we could just do -Wno-conversion in the makefile, and we wouldn't > > have to do any work here at all. > > These warnings weren't implemented just to irritate us. They were implemented > because C is the basement of C++ and there are bugs hiding in its dark corners.
That is a beautiful metaphor, but can you be a little more concrete? The integer conversion is the same between C and C++, and the warnings are applied to all C code. That doesn't mean that our C code would has the same kind of problems, and that the impact of those problems warrant investment to address them. I mean, if we were writing a new SSL library, I surely would want scrutiny on every cast, but we aren't. In LilyPond, the bulk of the warnings come from unsigned 64 bit sizes, ie. vector and list sizes. In order to cause an error, you would have to create vector or list of over 2G of elements (on 32 bit architecture), so the unsigned size would be converted to a negative integer. Since our objects are all larger than a single byte, there isn't enough memory for this to be possible. (The same holds for 64 bit, except that you can't buy machines with that much RAM) Similarly, for causing a problem by converting 64-bit size_t to a 32-bit int, you'd have to create something with a size of over 2e9. What kind of score do you have in mind that would cause this problem? > My answer would be different if this were one of those categories of warnings > with a significant number of false positives, but it isn't, as far as I've seen. Can you point me to a conversion warning in LilyPond which could cause a genuine, user-visible problem? https://codereview.appspot.com/557190043/
