Re: STL bug with 4.0?
Re: STL bug with 4.0?
- Subject: Re: STL bug with 4.0?
- From: Scott Andrew <email@hidden>
- Date: Tue, 22 Nov 2005 09:31:55 -0800
So this seemed to be a difference in STL implemenations. When we
called sort our sort predicate did a check, it did a <= check. In GCC
4.0 there is no check for hitting the middle or end of the list when
doing a sort the <= check in cases returned true enough to where it
finally just ran of the end of the vector.
However we changed to just < and all is well
Scott Andrew
On Nov 21, 2005, at 5:36 AM, Howard Hinnant wrote:
On Nov 20, 2005, at 11:11 PM, Scott Andrew wrote:
__unguarded_partition bug? I have some code that is call std::sort
of 50K of items. It seems that somewhere down the line that
__unguarded_partition is loosing a pointer and trying to read
beyond where it should. has onyone see this issue. Are there
patches to the STL files anywhere?
I have reviewed __unguarded_partition, and its role within sort. I
have searched both this list, and the gcc lists for report of a
problem with sort and/or __unguarded_partition. I can not find any
evidence of a bug. Would it be possible for you to send us a demo
of this problem?
The only way I can currently see for __unguarded_partition to read
beyond where it should is if the comparison operator/data set does
not form a strict weak ordering. This could happen for example, if
using the built-in less than operator on floating point types. If
a nan creeps into the data, less-than no longer forms a strict weak
ordering. For example if x is a nan, and y is 3, and z is 6 then:
!(x < y) && !(y < x) -> true, x (nan) and y (3) are equivalent
!(x < z) && !(z < x) -> true, x (nan) and y (6) are equivalent
Therefore, if this is a strict weak ordering, y (3) and z (6) are
also equivalent (which is obviously false).
The problem could be either in a faulty comparison operator, or in
a corrupted range containing data over which the comparison
operator isn't valid.
Switching sort implementations may not fix this behavior, or worse
yet, it might make the behavior harder to detect.
Compiling with the compiler flag -D_GLIBCXX_DEBUG (STL debug mode),
may help expose the root cause of this problem.
-Howard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden