{"id":94405,"date":"2016-09-28T07:00:00","date_gmt":"2016-09-28T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=94405"},"modified":"2019-03-13T11:07:18","modified_gmt":"2019-03-13T18:07:18","slug":"20160928-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20160928-00\/?p=94405","title":{"rendered":"When can you free the memory backing the HSTRING you created with WindowsCreateStringReference?"},"content":{"rendered":"

A little while back, I posted my complete guide to HSTRING semantics<\/a> (a rip-off of Eric’s complete guide to BSTR semantics<\/a>). A discussion of security descriptor lifetime somehow triggered the question “When can you free the memory backing the HSTRING<\/code> you created with Windows­Create­String­Reference<\/code><\/a>?” <\/p>\n

You can free the memory backing the HSTRING<\/code> after you destroy the HSTRING<\/code>, and since this is a fast-pass string, you destroy the HSTRING<\/code> by simply abandoning it. Therefore, you can free the memory when you know that nobody should have a copy of the fast-pass HSTRING<\/code> handle any more. <\/p>\n

(For the purpose of terminology, I’m going to say that you have a “copy” of an HSTRING<\/code> handle if you merely copied the HSTRING<\/code> handle. E.g., HSTRING copy = hstr;<\/code> On the other hand, I’m going to say that you have a “duplicate” of an HSTRING<\/code> if you passed it to Windows­Duplicate­String<\/code>.) <\/p>\n

Okay, so how do you know that nobody has a copy of the fast-pass HSTRING<\/code> handle any more? <\/p>\n

Recall the rules for HSTRING<\/code>s: If a function is passed an HSTRING<\/code> and it wants to save the HSTRING<\/code> for future use, it must use Windows­Duplicate­String<\/code> to increment the reference count on the string (and possibly convert it from fast-pass to standard). Therefore, if you pass the HSTRING<\/code> to another function, you know that there are no copies of that HSTRING<\/code> handle when the function returns, because creating a copy is not allowed. The only place where a literal copy of the HSTRING<\/code> handle is allowed is in the function that created it, and therefore you know when there are no more copies of the HSTRING<\/code> handle because all of the copies belong to you. <\/p>\n

The question sort of acknowledges this rule, but notes, “All it takes is one bug somewhere in all of WinRT where someone forgets to duplicate a input string if they need said string later after the function has returned.” <\/p>\n

That’s true. But it’s true of C-style string pointers, too! If you pass a C-style string to another function, and that other function wants to retain the string, it’s going to need to call strdup<\/code> or some other string duplication function so it can have its own private copy of the string. The value received as a function parameter is not valid once the function returns; if you need to use it after the function returns, you need to duplicate the string. <\/p>\n

Similarly, if you receive a COM interface pointer, and you want to continue using it after the function returns, you need to call IUnknown::AddRef<\/code> to increase the reference count on the interface, corresponding to the copy of the pointer you retained. When you’re done with the pointer, you call IUnknown::Release<\/code>. <\/p>\n

In both of these cases, you are relying on people writing code to respect these rules. All it takes is one bug somewhere in all of C where someone forgets to duplicate a input string if they need said string later after the function has returned. <\/p>\n

Somehow, we’ve managed to survive working with C-style strings and with COM interface pointers with these rules. Maybe it’s with the help of things like smart pointers, or maybe it’s just through good discipline. Whatever the reason, keep up the good work. <\/p>\n

Bonus chatter<\/b>: One of the rules for fast-pass strings is that you cannot change the contents of the string as long as the HSTRING<\/code> is still in use. One commenter interpreted this to mean that string references aren’t thread-safe. Not true. Rather, the statement is a direct reflection of the fact that an HSTRING<\/code> is immutable. If you changed the contents of the buffer that backs the HSTRING<\/code>, then you break the immutability rule. Thread safety is not at issue here. You can use a fast-pass string from any thread you like, as long as you stop using it before your function returns. (This means that your function cannot return until the other thread has definitely finished with the fast-pass string. In practice, this is not commonly done; instead, the function uses Windows­Duplicate­String<\/code> to create a standard HSTRING<\/code> and passes that HSTRING<\/code> to the other thread, which can then Windows­Delete­String<\/code> the HSTRING<\/code> when it is done.) <\/p>\n","protected":false},"excerpt":{"rendered":"

Nothing you haven’t had to deal with already.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-94405","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

Nothing you haven’t had to deal with already.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/94405","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=94405"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/94405\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=94405"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=94405"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=94405"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}