[GiNaC-list] Use of STL iterators in GiNaC

[Michael Goffioul]

On Thu, Apr 16, 2009 at 12:10 PM, Jens Vollinga <jensv at 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.