Got weird crashes at customers with foreign languages? Microsoft’s MFC’s MakeLower could be the culprit. Seems to be poorly written because it can crash if it doesn’t like the string. I could even reproduce it here by switching the Windows-Locale for non-unicode apps the Japanese and process some strings contains German umlauts. Bottom-line? Don’t use, write your own… 🙁
The third (and I hope final) dangerous posting.
This code looks harmless enough:
CFileStatus rStatus; CFile::GetStatus (MyFilename, rStatus);
And it will work most of the time. But CFileStatus uses CTime, which is limited to dates after 1.1.1970. If you apply this code to a file with a file-modification date of e.g. 1.1.1960, GetStatus will raise an exception. (Which it isn’t documented to to.) And if you don’t catch that, it will terminate your program.
It took quite some time until I found this bug. Here’s a simplified version of what caused it:
char dir[2048];
GetCurrentDirectory(2048, dir);
printf(CString("Current dir is:")+dir));
That’s doesn’t look bad, does it? And (like in the great programmer quotes), it works on my computer. But it doesn’t work if the customer’s current folder is something like “%&§something”, because it contains %s.
So don’t throw any external data at the first parameter of printf, sprintf, etc; instead put it into the following parameters.
printf(“Current dir is: %s”, dir);
COleDateTime::ParseDateTime is a handy function to parse a date string into a COleDateTime (and then SYSTEMTIME and then CTime).
The problem is that the expected date format depends on the user’s system settings. If you’re parsing a string that is always in the same format (from a file or from the internet), then parsing might work on your computer, but fail on the customer’s computer (in another country).
Solution: Use the locale ID parameter to force the parsing language.
