Repository navigation
URLHost not robust when re-setting its value #18302
Description
Activity
- addedwhatwg-urlIssues and PRs related to the WHATWG URL implementation.Issues and PRs related to the WHATWG URL implementation.c++Issues and PRs that require attention from people who are familiar with C++.Issues and PRs that require attention from people who are familiar with C++.
on Jan 22, 2018 this->~URLHost()I’m just going to mention again that I’d prefer something like a
Reset()method instead that we could call in these setters and in the destructor – calling the destructor of on object explicitly seems pretty icky, especially when we can avoid it. ;)(That being said, I’d consider this worthy of being a good first issue if somebody wants to do some C++ stuff?)
Reacted by Timothy Gu- addedgood first issueIssues that are suitable for first-time contributors.Issues that are suitable for first-time contributors.
on Jan 23, 2018 I've marked this as a good first issue and mentor available. I'm happy to assist anyone that wants to take this on, it should be a very simple change.
If anyone's considering this: all that's required is to make a private
Resetmethod onURLHostthat contains the current contents of the destructor, then call it from the destructor,SetDomain&SetOpaque.@apapirovski Alright, I`ll do this one then :)
Reacted by Anatoli Papirovski- added a commit that references this issue
on Feb 1, 2018 - added a commit that references this issue
on Mar 20, 2018 - added 2 commits that reference this issue
on Mar 28, 2018 - added a commit that references this issue
on Apr 1, 2018 - added a commit that references this issue
on Apr 13, 2018 - added a commit that references this issue
on May 8, 2018
Currently, the
SetOpaque()andSetDomain()methods ofURLHostclass innode_url.ccalways overwrite the existing string invalue_without disposing of the original value in that union.node/src/node_url.cc
Lines 95 to 112 in a3555d0
This could cause a memory leak when these two methods are used on an instance of the class on which one of these two methods has already been called.
Right now that never happens because of the way the URL parsing state machine is designed, but ideally these two methods should first call
this->~URLHost()to free any memory already allocated before reinitializing thevaluethrough thenewplacement.