Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modernize lua read (part 2 & 3): C++ templating assurance #7410

Merged
merged 21 commits into from
Jun 30, 2018

Conversation

nerzhul
Copy link
Member

@nerzhul nerzhul commented Jun 4, 2018

Implement the boolean reader
Also remove unused & unimplemented script_error_handler
move readers to a new LuaHelper class permitting to share code between Lua interfaces

Implement the boolean reader
Also remove unused & unimplemented script_error_handler
template<>
bool LuaHelper::readParam(lua_State *L, int index)
{
return lua_toboolean(L, index) != 0;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a question: should i add a throw LuaError with not a bool here to use strong bool or not ? we are lazy on checks

Implement the std::string reader
Also be strict with boolean checks, C++ doesn't define false as the boolean default value, it's undef
Fix some wrong type checks in some code parts, detected when enabled string and boolean strict type checking
@nerzhul
Copy link
Member Author

nerzhul commented Jun 5, 2018

Note, the parts are not to be squashed. I tested it with mtg without having problems, but the strict checking on bool can either fix some random bugs (undefined default bool in some calls) or permit mods to fix some implementation bugs

@nerzhul
Copy link
Member Author

nerzhul commented Jun 5, 2018

Note to @SmallJoker : LuaError is catched by serverstep or client step and shown with a backtrace properly :)

return "";

if (!lua_isstring(L, index))
throw LuaError(luahelper_type_error(index, "string"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

luaL_checkstring does the same in one line.

template <> std::string LuaHelper::readParam(lua_State *L, int index)
{
if (lua_isnil(L, index))
return "";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some places it's best to throw an error since a proper string value is expected.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i agree with you, first i didn't added this but we had many stack traces with regular MTG :) we can remove it later after fixing our upstream calls or i can remove it and we will fix it on each bug reported by end users

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's indeed bad. I would however prefer to fix those issues instead of silently accepting it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i remove it, and we are free to fix the engine crashes after :)

@@ -649,7 +649,7 @@ int ScriptApiSecurity::sl_g_loadfile(lua_State *L)
lua_pop(L, 1);

if (script->getType() == ScriptingType::Client) {
std:: string display_path = lua_tostring(L, 1);
std:: string display_path = readParam<std::string>(L, 1);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Space after ::

@@ -243,7 +243,8 @@ int ObjectRef::l_set_hp(lua_State *L)
lua_pushvalue(L, 3);

lua_getfield(L, -1, "type");
if (lua_isstring(L, -1) && !reason.setTypeFromString(lua_tostring(L, -1))) {
if (lua_isstring(L, -1) &&
!reason.setTypeFromString(readParam<std::string>(L, -1))) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing indent.

result.append(str);
}

return str;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be return result;?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops :) ty

@paramat
Copy link
Contributor

paramat commented Jun 28, 2018

What's the advantage of this, is lua parameter reading faster?

@nerzhul
Copy link
Member Author

nerzhul commented Jun 28, 2018

@paramat it's exactly same performance (in release mode, negligible in debug mode). The advantage if we implement the template on all types is that permit to access to lua reader/writer in a uniform, standardized and securized way. One high level function per type to perform the call with all security/sanitize it needs. it also permits to implement easily a complex reader in the same API (imagine writeParam<Json::Value>(L, json_val), for example)

It's basically a code quality implementation, and it can be (at the end) easily tested with unittests if we need it

@paramat
Copy link
Contributor

paramat commented Jun 28, 2018

Ok thanks, no objection from me. Unfortunately i'm not qualified to officially +1 it.

@nerzhul
Copy link
Member Author

nerzhul commented Jun 30, 2018

@SmallJoker if you are okay, i can merge this. It seems other qualified devs are not concerned about this

@nerzhul
Copy link
Member Author

nerzhul commented Jun 30, 2018

Approved by @SmallJoker on IRC

@nerzhul nerzhul changed the title Modernize lua read (part 2): C++ templating assurance Modernize lua read (part 2 & 3): C++ templating assurance Jun 30, 2018
sfan5
sfan5 previously requested changes Jun 30, 2018
*/
template <> bool LuaHelper::readParam(lua_State *L, int index)
{
return lua_toboolean(L, index) != 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should have a comment why luaL_checkboolean is not used here

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this function doesn't exists in Lua & has been dropped from the header, as it seems useless currently (i added this in a previous version of this PR)

return lua_toboolean(L, index) != 0;
}

template <> bool LuaHelper::readParam(lua_State *L, int index, const bool &dv)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

clarity: dv -> default

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

default is a protected keyword in C++11 standard

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also dv is described in the header comments

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well then default_ and fallback_value would still be an option

@nerzhul nerzhul dismissed sfan5’s stale review June 30, 2018 13:09

answers given

@nerzhul nerzhul merged commit eef62c8 into minetest:master Jun 30, 2018
@nerzhul nerzhul deleted the modern_lua_read_2 branch June 30, 2018 15:11
@rubenwardy rubenwardy added Maintenance Tasks to keep the codebase and related parts in order, including architectural improvements and removed Maintenance Tasks to keep the codebase and related parts in order, including architectural improvements labels Jul 26, 2018
osjc pushed a commit to osjc/minetest that referenced this pull request Jan 23, 2019
)

* Modernize lua read (part 2 & 3): C++ templating assurance

Implement the boolean reader
Implement the string reader
Also remove unused & unimplemented script_error_handler
Add a reader with default value
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@ Client Script API Maintenance Tasks to keep the codebase and related parts in order, including architectural improvements @ Script API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants