On Thu, 18 Jan 2007, Manuel López-Ibáñez wrote: [...]
| > As the PR you noted, it wasn't part of C++. | > | | You are wrong. "the PR you noted" is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26167#c3 which you described as your favorite. The PR starts with this gcc reports the signedness probelm correctly, but g++ does not. See below for a demonstration: [...] | > You never re-evaluate based on data collected from experimenting with | > applications out there? | > | | Yes, I do. Good. [...] | > Look at the code at issue in libstdc++. What is wrong with it? | > As noted by Joe, such constructs are now likely common place, as they | > fall from STL-style view of sequences. You have to take that into | > account. | | What is wrong with it is that if the difference between the two ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | pointers is negative you could obtain an unexpected result when this ^^^^^^^^^^^^^^^^^^^^ | negative value is converted to unsigned. But, it isn't. I asked what *is* wrong with it; not what might be wrong with it in a speculative world. The fact is nothing is wrong with it. | Can we detect that this | cannot happen or that it doesn't matter? Is there any distinctive case | where we can detect that it matters and we should warn? | | Assigning negative values to unsigned types is a typical security | vulnerability, it doesn't matter if you do it in complement-2 | arithmetic. The result is not what the programmer (who may be unaware | of the unsigned type because it is hidden behind a typedef) expected. | So some cases of sign->unsigned are worth warning. Can we detect | those? | | > | Finally, why libstdc++ is using Wconversion at all? | > | > Please go and read the PR submitted by Gerald. | | I read it and still don't get it. So, you did not get that libstdc++ was not using -Wconversion? That is troublesome. -- Gaby
