[5.0] avoid using a stack variable after return

[spoonincode]

http_max_response_time is a variable declared on that stack as part of plugin_startup()

leap/plugins/producer_api_plugin/producer_api_plugin.cpp

Line 94 in c301152

fc::microseconds http_max_response_time = http.get_max_response_time();

CALL_WITH_400 captures all by reference

leap/plugins/producer_api_plugin/producer_api_plugin.cpp

Lines 23 to 26 in c301152

	#define CALL_WITH_400(api_name, category, api_handle, call_name, INVOKE, http_response_code) \
	{std::string("/v1/" #api_name "/" #call_name), \
	api_category::category, \
	[&](string&&, string&& body, url_response_callback&& cb) mutable { \

INVOKE_R_R_D then goes on to use the reference to http_max_response_time which is stale as plugin_startup() has long since returned once HTTP requests are made

leap/plugins/producer_api_plugin/producer_api_plugin.cpp

Lines 65 to 66 in c301152

	#define INVOKE_R_R_D(api_handle, call_name, in_param) \
	auto deadline = http_max_response_time == fc::microseconds::maximum() ? fc::time_point::maximum() \

This problem seemed to have been introduced in 5.0. Since this is in producer_api, which isn't expected to ever be exposed publicly, not considering this a security defect.

[heifner]

Seems like it would be safer to capture all by value = in CALL_WITH_400 instead of all by reference &.

leap/plugins/producer_api_plugin/producer_api_plugin.cpp

Lines 23 to 26 in c301152

	#define CALL_WITH_400(api_name, category, api_handle, call_name, INVOKE, http_response_code) \
	{std::string("/v1/" #api_name "/" #call_name), \
	api_category::category, \
	[&](string&&, string&& body, url_response_callback&& cb) mutable { \

[ericpassmore]

Note:start
group: CLEANCODE
category: INTERNALS
summary: Cleanup usage of stack variables in producer api plugin.
Note: end

[spoonincode]

safer

Well, personally for non-trivial usages of lambdas -- such as this case -- I like to see explicit capture lists. So [&producer, &http] in this case. Does that work?

[heifner]

safer

Well, personally for non-trivial usages of lambdas -- such as this case -- I like to see explicit capture lists. So [&producer, &http] in this case. Does that work?

Sounds good.

[spoonincode]

that was probably a bad idea since now clang warns of unused lambda captures