Localization Bugs: String length limitations, #3

Last time, I gave a couple of examples how even if you use safe coding practices, localization might still break your code. Of course, the problem wasn't really that you used strncpy instead of strcpy, the problem was the string length limitation itself. From which follows that the solution would not be to use strcpy instead of strncpy, but to either increase the buffer size or communication the limitations with the localization team, as appropriate.

Just for fun, let's think about what can go wrong when strcpy is used instead of strncpy. Well, we'd probably avoid the example I gave when truncation of a string leads to mismatched placeholders, which in turn leads to garbage text or access violations. But instead, we probably trade that for a buffer overrun, which gives us - guess what - probably garbage text or an application crash. Great.

What's interesting here - and this is something I want to write more about later - is that you as a developer or pm or tester or whatever need to ask yourself, "how much do I trust my localizer?" What if your localizer finds one of these buffer overflows, what if it's in an interesting place, what if he manages to craft a "malicious translation"?

Unlike code, localization might not be subjected to a thorough security review. Oh, so there might be linguistical review, there might be functional testing done - but really, are you looking for localization-specific security issues? Is your code prepared for them?

...I digress... I really want to write more about localization & security, but not right now. I need to show some more classes of localization bugs first.

That's it for today. Next time I'll talk about how I trouble shoot the symptoms of a string length limitation, and later what we do to hunt them down before we even start localizing.

This posting is provided "AS IS" with no warranties, and confers no rights.