Re: STL objects and binary compatibility
Triple-DES <DenPlettfrie@gmail.com> wrote in
news:0d7d6a42-4712-4a9c-b7e5-07f5d9e0486c@k37g2000hsf.googlegroups.com:
On 13 Mai, 01:35, Paavo Helde <nob...@ebi.ee> 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) {
? ? ? ? double sum=0.0;
? ? ? ? for(const double* p=from; p!=to; ++p) {
? ? ? ? ? ? ? ? sum += *p;
? ? ? ? }
? ? ? ? return sum;
}
int main() {
? ? ? ? std::vector<double> v;
? ? ? ? v.push_back(3.1415926);
? ? ? ? v.push_back(2.7182818);
? ? ? ? size_t n=v.size();
? ? ? ? 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. ?We 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].
Yes, that's why I added another example where it could not be avoided
*so* easily. Also here, &v[0] fails for an empty vector.
These are actual examples from a former coworker code, which stopped
working in a new compiler version. I have fixed all locations I have
found of course. I'm worried about locations which I might have not
found.
Regards
Paavo