-
Notifications
You must be signed in to change notification settings - Fork 7.9k
uri: Stop touching the lxb_url_parser_t.idna
field
#19592
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
Conversation
Looking at the Lexbor implementation, the `lxb_url_parser_t.idna` field is private and must not be touched from the outside. Lexbor expects to be able to manage it by itself when destroying a parser object. Fix the issue by putting the `lxb_unicode_idna_t` into a thread-local variable that we own. This also avoids one level of dynamic allocation. The same is done for the mraw.
} | ||
|
||
PHP_RSHUTDOWN_FUNCTION(uri_parser_whatwg) | ||
{ | ||
lxb_url_parser_memory_destroy(&lexbor_parser); | ||
lxb_unicode_idna_destroy(&lexbor_idna, false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose the destroy logic may be separated to another function that gets called from RSHUTDOWN and the failure path in RINIT.
Anyway, this is only a small remark
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I considered that, but thought that being explicit here is useful, since the use-cases are a little different: The failure in RINIT might need to correctly handle partial initialization, whereas the cleanup in RSHUTDOWN can rely on proper initialization.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure
/* Unconditionally calling the _destroy() functions is | ||
* safe on a zeroed structure. */ | ||
lxb_unicode_idna_destroy(&lexbor_idna, false); | ||
memset(&lexbor_idna, 0, sizeof(lexbor_idna)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure if it's strictly necessary to use memset as Lexbor seems to reset the fields. But extra safety is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lexbor_mraw_destroy()
does not reset the ref_count
. It's correctly reset in lexbor_mraw_init()
, but I'd rather not take chances when the initialization fails halfway through or other dumb stuff like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ait
Looking at the Lexbor implementation, the
lxb_url_parser_t.idna
field is private and must not be touched from the outside. Lexbor expects to be able to manage it by itself when destroying a parser object.Fix the issue by putting the
lxb_unicode_idna_t
into a thread-local variable that we own. This also avoids one level of dynamic allocation. The same is done for the mraw.