Triple-DES <DenPlettfrie@[EMAIL PROTECTED]
> wrote in
news:0d7d6a42-4712-4a9c-b7e5-07f5d9e0486c@[EMAIL PROTECTED]
> 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) {
>> 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
|
