------- Comment #5 from nam3l3ss dot bugreportaccount at gmail dot com 2008-01-04 03:31 ------- Of course, if you add the check for the appropriate type of end iterator right before the find gets called, the problem goes away without a trace.
Btw and imho, the worst thing that find may get as __first, is and end iterator, as suggested by the fact stated a few lines earlier. Sadly, I'm not yet familiar with the method the STL uses to construct iterators for template containers, but it seems logical for me, that for the a = *b assignment, where, a is, let's say, a vector, and b is an iterator over vectors, for example, returned by a find, the end iterator, which can appear as 'b' has to be able to live up to the expectations and get assigned to a. If this is the case, then the end iterator should call the vector's default constructor upon it's creation, meaning, its start iterator equals its end iterator, so it cannot possibly be invalid, for AFAIK searching beetween two end iterators is equivalent with a SKIP. If the end iterator does not behave like this, then of course in the case of an end iterator over vectors would not cause all kind of errors upon access. (Of course, if you refer to element 10 when there is no such, because the absence of safety methods, there will be an error, but in the case of STL iterators, these methods are provided, or so I think so.) Even if the above reasoning is faulty (witch is admit is likely, since I made my third mistake by attaching a file while trusting text upon a fragile html textbox, and so, losing the first version of this comment. I apologize for this second version's poor quality.) However, I'd like to know what exactly you meant by 'invalid'. The first and second mistakes were not stating exactly where this code managed to run without errors, and not checking the preprocessed code there, for they differ in some places. I attached the working code, it was created in the following environment: Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) It works flawlessly on that. I'm curious, is this a regression, of an advancement, or what?:) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34650
