getWords("a b c d", 2); // "c d"
that turns into this inside the engine:
getWords("a b c d", 2, 1000000);
that code after parsing d goes string++ which passes over the null character. This now enforces that check. Found this with the new script interpreter...how this wasn't blowing up before is beyond me.
Added sanity check for findMatch
Finished most of asset importer logic to utilize settings system
Cleaned up code for finding associated files
Added General importer settings category and integrated logic for those settings fields
Updated logic in variableGroup to support callbacks in custom fields
Updated logic in variableInspector to better handle callbacks, as well as being able to manually update when manipulating fields
Updated scripts to utilize project settings values for playGUI and mainMenuGUI names
Improved module-oriented loading of materials
Added util function for populating custom fonts
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
