When using the libstdc++ debug mode, some invalid iterator uses are not diagnosed, e.g. the following program compiles and runs without aborting / any diagnostic: ------------------------------------------------------------------ #include <vector> int main() { std::vector<int> v(1, 1); v.insert(v.begin(), v.begin(), v.end()); } ------------------------------------------------------------------- In the call to vector::insert, the range to insert points into the vector to insert into. This violates the precondition as specified for sequence containers. A similar precondition exists for sequence container assign members and maybe others. It would be nice if this misusage could be diagnosed. The matter is a bit more complicated because in a "insert(p, i, j)" call, i and j may be arbitrary input iterators forming a range. Example: ----------------------------------------------------------- #include <vector> int main() { std::vector<int> v(1, 1); v.insert(v.begin(), v.data(), v.data() + 1); } ------------------------------------------------------------ Here the iterators i and j are plain pointers. The full compiler command line I used was: ----------------------------------------------------------- c++ -Wall -Wextra -pedantic -std=c++0x -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -o container_insert_iterators_into_container.debug_enhancement container_insert_iterators_into_container.debug_enhancement.cc -g -fstack-protector-all -pthread --------------------------------------------------------- The output of "c++ -v" is: ---------------------------------------------------------- Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.7.3 (SUSE Linux) ----------------------------------------------------------
Maybe Francois is interested.
Sure I can take care of it. The Standard is saying that for any sequence type this insert operation shall not take a range pointing back to the sequence. I plan to rather check the libstdc++ limits as most of its containers allow this kind of insertion. For the moment I think that only std::vector and std::deque are in this situation, maybe std::string, I will double check. The proposed use case is indeed a bit more complicated, I will see if I can cover it too.
Even if our implementation doesn't misbehave in those cases, a DEBUG_PEDASSERT could be in order (like we do in, eg, basic_string::operator[])
Done for 4.9.0 then.