We've supposed to not use 'string' as a variable name even in C-code, to make sure we don't have problems with C++.
How is that even a problem? "string" is in no way a C++ keyword, "std::string" is in a namespace, and local variables can shadow types. The issues with C++ compatibility arise when using "new", "delete", or other keywords as variable or function names.
Reply To (Anonymous)
We've supposed to not use 'string' as a variable name even in C-code, to make sure we don't have problems with C++.
"std::string" is in a namespace
Yea, it's unlikely that there's problems in any modern setup, but back in the days when it was customary for everyone to be "using namespace std" in whatever system header we faced problems with variables named 'string' (maybe as late as when we introduced Qt-client, but certainly back when we were using C++ based tolua fork)
Should note that his *reduces* diff between savegame3.c and savegame2.c (that diff was the reason I noticed this, as the same patch did not apply to both). Even if we completely ignore C++ aspect, I think this is still worth pushing in, for easing efforts to fix issues in savegame?.c modules (there's quite a many open ones at the moment)
We've supposed to not use 'string' as a variable name even in C-code, to make sure we don't have problems with C++. savegame2.c still seems to use such variables.