Jacek Caban (@jacek) commented about dlls/iertutil/uri.c:
+ { + result->absolute_uri = strdupwn(result->raw_uri, result->raw_uri_len); + result->absolute_uri_len = result->raw_uri_len; + result->display_uri = strdupwn(result->raw_uri, result->raw_uri_len); + result->display_uri_len = result->raw_uri_len; + return; + } + + /* AbsoluteUri includes userinfo. DisplayUri includes them only for unknown schemes */ + result->absolute_uri = uri_runtime_build_uri(result, TRUE, &result->absolute_uri_len); + result->display_uri = uri_runtime_build_uri(result, !result->is_known_scheme, &result->display_uri_len); +} + +/* Parse the URI using the URI parser for CreateUri(). Then build the URI components for + * IUriRuntimeClass, the behavior of which is a bit different compared to CreateUri() */ +HRESULT uri_runtime_parse(const WCHAR *uri, struct uri_runtime_data *result) Since this is all internal, that kind of layering does not seem necessary. Could we instead have `parse_uri` flag(s) to trigger the desired behavior in the first place?
Also, given that individual URI components are just a substring of the entire URI, most of those allocations seem redundant. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9131#note_133770