address of h2o_pathconf_t should not change when more paths are added #2254
Conversation
| @@ -272,7 +272,7 @@ static mrb_value build_constants(mrb_state *mrb, const char *server_name, size_t | |||
| mrb_ary_set(mrb, ary, i, lit); | |||
| } | |||
| for (; i != H2O_MAX_TOKENS * 2; ++i) { | |||
| const h2o_token_t *token = h2o__tokens + i - H2O_MAX_TOKENS; | |||
| const h2o_token_t *token = h2o__tokens + (i - H2O_MAX_TOKENS); | |||
There was a problem hiding this comment.
This change is not related to what this PR wanted to fix, but undefined behavior sanitizer warns without this parenthesis because h2o__tokens + i overflows.
…y already be other paths (ex: path for http2-debug-state)
|
Thank you for filing the pull request. Am I understanding correctly that the issue is that the a handler might remember the address of Assuming that is the case, I think we should consider what the contract we want to have between libh2o and applications (with the standalone server being a user of libh2o in this context), rather than resolving the problem by modifying the order in which we call the functions from the configurator. Specifically, I think the question is if applications can assume the address of If the answer is no, I think we should stop returning If the answer is yes, we should change the way the list of paths are maintained, so that the addresses of paths do not change once each of them is registered. |
I think the ideal answer is Yes, they should be not changed. So I commited 7172457 |
i110
force-pushed
the
i110/mruby-pathconf-dangling-pointer
branch
from
7172457
to
97168a5
Compare
kazuho
changed the title
Fix #2234
hostconf->pathsmay be reallocated inh2o_config_register_path, but currently mruby handler has its reference. This PR fixes it by registering all paths at first, then configuring all paths