Re: STL objects and binary compatibility

On 13 Mai, 01:35, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
> Maybe I should have been more precise. The alarms are not "false" in the
> sense that the code has UB by the standard. On the other hand, the code
> appears to have defined meaning and guaranteed behavior by the same
> implementation which raises the alarms. Example 1:
>
> #include <vector>
> #include <iostream>
> #include <ostream>
>
> double summate(const double* from, const double* to) {
> =A0 =A0 =A0 =A0 double sum=3D0.0;
> =A0 =A0 =A0 =A0 for(const double* p=3Dfrom; p!=3Dto; ++p) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 sum +=3D *p;
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 return sum;
>
> }
>
> int main() {
> =A0 =A0 =A0 =A0 std::vector<double> v;
> =A0 =A0 =A0 =A0 v.push_back(3.1415926);
> =A0 =A0 =A0 =A0 v.push_back(2.7182818);
> =A0 =A0 =A0 =A0 size_t n=3Dv.size();
> =A0 =A0 =A0 =A0 std::cout << summate(&v[0], &v[n]) << "\n";
>
> }
>
> In real life, summate() is some legacy function accepting double*
> pointers, which has to be interfaced with a new std::vector array used
> for better memory management. The expression &v[n] is formally UB. VC++
> on XP crashes the application with the message "test.exe has encountered
> a problem and needs to close. =A0We are sorry for the inconvenience.".
If
> _SECURE_SCL is defined to 0, the program runs nicely and produces the
> expected results.

I think the problem is not only formal in this case, because the
expression v[n], or v.operator[](n) dereferences an invalid pointer.
Okay, the program may happen to work, but the checked iterator alarm/
crash is justified by the fact that it exposes a potential problem
that could easily be avoided by using (&v[0] + n) instead of &v[n].

--
DP