On Thu, Apr 16, 2009 at 12:10 PM, Jens Vollinga <jensv@nikhef.nl> wrote:
Hi,
Michael Goffioul schrieb:
I'm currently tracking down these issues by running the test suite in the source package, but this might not catch all of them. If you are interested, I can send a patch once I succeed to run the test suite completely.
yes, that would be interesting! I'd like to see where this happens. I don't have access to a VC compiler to try it myself, though.
(ref your patch) There are more issues than the ones you mention, at least with VC++. I'll provide a full patch in the coming days, but here are some examples: ncmul.cpp: ncmul::eval(int), ~line 350 rettypes has the right capacity (due to the "reserve" call), but a size of 0. Then using "rettypes[0]" makes VC++ to raise an exception, due to internal bound checking. About this, I'm not sure what the standard says, but when I look at http://www.sgi.com/tech/stl/RandomAccessContainer.html the precondition is not met. utils.h: permutation_sign(), ~line 184 If I understand the code correctly, "other" is kept one position before "i". When "i" reaches "first", "other" is one position before. But when "first"equals std::vector::begin(), you end up decrementing begin(). factor.cpp: modular_matrix::mul_col(), ~line 697 When rc == (r-1), "i" gets past end().
I see no problem with dereferencing end(), and doing operations like end()+<integer>. In that case, end() should return a proper iterator as a temporary and on these the operations +,- are defined (somewhere 24.1.5 in the standard, I believe). But maybe there is a ++ or -- involved?
I'm no C++ standard expert, but when I look at http://www.sgi.com/tech/stl/RandomAccessIterator.html my understanding of the precondition for "i += n" is that you cannot go after end(). To be honest, I know VC++ is by far the worst standard compliant compiler, but in all the situations mentioned above, I had the impression that ginac's code relied on undefined behaviors that happen to work fine on gcc/glibc. Bye, Michael.