dnsdist: Fix warnings reported by clang's analyzer and cppcheck #6407
Conversation
pdns/dnsdist-lua.hh
Outdated
| @@ -25,7 +25,7 @@ class LuaAction : public DNSAction | |||
| { | |||
| public: | |||
| typedef std::function<std::tuple<int, boost::optional<string> >(DNSQuestion* dq)> func_t; | |||
| LuaAction(LuaAction::func_t func) : d_func(func) | |||
| LuaAction(LuaAction::func_t& func) : d_func(func) | |||
There was a problem hiding this comment.
Maybe const LuaAction::func_t& func ?
pdns/dnsdist-lua.hh
Outdated
| @@ -40,7 +40,7 @@ class LuaResponseAction : public DNSResponseAction | |||
| { | |||
| public: | |||
| typedef std::function<std::tuple<int, boost::optional<string> >(DNSResponse* dr)> func_t; | |||
| LuaResponseAction(LuaResponseAction::func_t func) : d_func(func) | |||
| LuaResponseAction(LuaResponseAction::func_t& func) : d_func(func) | |||
There was a problem hiding this comment.
Maybe const LuaResponseAction::func_t& func ?
| @@ -324,12 +337,10 @@ struct ClientState; | |||
| struct IDState | |||
| { | |||
| IDState() : origFD(-1), sentTime(true), delayMsec(0), tempFailureTTL(boost::none) { origDest.sin4.sin_family = 0;} | |||
| IDState(const IDState& orig) | |||
| IDState(const IDState& orig): origRemote(orig.origRemote), origDest(orig.origDest) | |||
There was a problem hiding this comment.
Why not also moving other member variables in initialization list ? (origFD, origID, delayMsec and tempFailureTTL)
There was a problem hiding this comment.
I had to keep the initialization of some members in the constructor body (copy constructor is missing for std::atomic for example), so I only changed the ones that mattered, ie non-Plain Old Data types.
| { | ||
| d_name = rr.qname; | ||
| d_type = rr.qtype.getCode(); | ||
| d_ttl = rr.ttl; |
There was a problem hiding this comment.
Same remark as with IDState(). But I may be missing something. Sorry if that's the case.
|
Pushed a fix to constify the function references passed to |
Short description
Mostly non-noticeable performance hints:
LuaWrappermoving the function variable before using it again might be a real issue though, and the locks' move constructor might have become one at some point.Checklist
I have: