\nFor functions that return data,\nthe contents of the output buffer if the function fails are typically\nleft unspecified.\nIf the function fails, callers should assume nothing about the contents.\n<\/P>\n
\nBut that doesn’t stop them from assuming it anyway.\n<\/P>\n
\nI was reminded of this topic after reading\n\nMichael Kaplan’s story of one customer who wanted the output buffer\ncontents to be defined even on failure<\/A>.\nThe reason the buffer is left untouched is because many\nprograms assume that the buffer is unchanged on failure,\neven though there is no documentation supporting this behavior.\n<\/P>\n \nHere’s one example of code I’ve seen (reconstructed) that relies\non the output buffer being left unchanged:\n<\/P>\n \nThis code fragment starts out with a fallback key then tries\nto open a “better” key,\nassuming that if the open fails,\nthe contents of the \nHere’s another example\n\nfrom actual shipping code<\/A>.\nObserve that the \nI don’t mean to pick on that code sample.\nIt was merely a convenient example\nof the sorts of abuses that Win32 needs to sustain\non a regular basis for the sake of compatibility.\nBecause, after all, people buy computers in order to\nrun programs on them.\n<\/P>\n \nOne significant exception to the “output buffers are undefined on failure”\nrule is output buffers returned by COM interface methods.\nCOM rules are that output buffers are always initialized, even on failure.\nThis is necessary to ensure that the marshaller doesn’t crash.\nFor example, the last parameter to the IUnknown::QueryInterface method\nmust be set to NULL on failure.\n<\/P><\/p>\n","protected":false},"excerpt":{"rendered":" For functions that return data, the contents of the output buffer if the function fails are typically left unspecified. If the function fails, callers should assume nothing about the contents. But that doesn’t stop them from assuming it anyway. I was reminded of this topic after reading Michael Kaplan’s story of one customer who wanted […]<\/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-34343","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" For functions that return data, the contents of the output buffer if the function fails are typically left unspecified. If the function fails, callers should assume nothing about the contents. But that doesn’t stop them from assuming it anyway. I was reminded of this topic after reading Michael Kaplan’s story of one customer who wanted […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/34343","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=34343"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/34343\/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=34343"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=34343"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=34343"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\nHKEY hk = hkFallback;\nRegOpenKeyEx(…, &hk);\nRegQueryValue(hk, …);\nif (hk != hkFallback) RegCloseKey(hk);\n<\/I><\/PRE>\n
hk<\/CODE> variable will be left unchanged\nand therefore will continue to have the original fallback value.\nThis behavior is not guaranteed by the specification for\n\nthe RegOpenKeyEx<\/CODE> function<\/A>, but that doesn’t stop people\nfrom relying on it anyway.\n<\/P>\nCRegistry::Restore<\/CODE> method is documented\nas “If the specified key does not exist, the value of ‘Value’ is unchanged.”\n(Let’s ignore for now that the documentation uses registry\nterminology incorrectly; the parameter specified is a value name,\nnot a key name.)\nIf you look at what the code actually does,\nit loads the buffer with the original value of “Value”,\nthen calls\n\nthe RegQueryValueEx<\/CODE> function<\/A> twice\nand ignores the return value both times!\nThe real work happens in the CRegistry::RestoreDWORD<\/CODE>\nfunction.\nAt the first call, observe that it initializes\nthe type<\/CODE> variable, then calls\nthe RegQueryValueEx<\/CODE> function and assumes that\nit does not modify the\n&type<\/CODE> parameter on failure.\nNext, it calls\nthe RegQueryValueEx<\/CODE> function a second time,\nthis time assuming that the output buffer\n&Value<\/CODE> remains unchanged in the event of failure,\nbecause that’s what CRegistry::Restore<\/CODE> expects.\n<\/P>\n