In an arithmetic expression, all the variables whose values can be represented with type 'int' will be promoted to this type. Therefore, the result of the '~mask' expression is a negative number. By the C++ standard, shifting a negative number to the left leads to an undefined behavior.
The behavior is different enough that these shouldn't be overloaded
with the non-allocating verions. Also makes it more obvious what is
going on to the caller.
A snippet of example code:
UTF16 pszFilter[1024];
...
convertUTF8toUTF16((UTF8 *)mData.mFilters, pszFilter, sizeof(pszFilter));
Since the conversion function is expecting the third parameter to be the
length in 16-bit characters, *not* bytes, this results in the function
writing outside the bounds of the output array.
To make this less likely to happen in the future (I hope), I've provided a
template function that infers the correct size of a static array, so it's
no longer necessary to pass the size in most cases. The sized function has
been renamed with an "N" suffix to hopefully encourage this use.
This bug was caught due to a warning from MSVC about stack corruption
occurring in codeBlock::exec(), after opening a file open dialog twice in
succession. After some hunting, I found that this was due to
FileDialog::Execute() passing incorrect buffer sizes to the conversion
function, which resulted in the function writing a null terminator into
some memory that happened to be in the stack frame of codeBlock::exec()!
* Made use of dStrIsEmpty in more locations (and fixed it :P)
* Removed commented-out code
* Corrected default params
* Fixed some console warning formats
* Removed tabs
* Corrected setExtent API
