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

Reply via email to