{"id":21883,"date":"2008-06-23T10:00:00","date_gmt":"2008-06-23T10:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2008\/06\/23\/just-because-youre-using-a-smart-pointer-class-doesnt-mean-you-can-abdicate-understanding-what-it-does\/"},"modified":"2008-06-23T10:00:00","modified_gmt":"2008-06-23T10:00:00","slug":"just-because-youre-using-a-smart-pointer-class-doesnt-mean-you-can-abdicate-understanding-what-it-does","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20080623-00\/?p=21883","title":{"rendered":"Just because you're using a smart pointer class doesn't mean you can abdicate understanding what it does"},"content":{"rendered":"

\nIt’s great when you have a tool to make programming easier,\nbut you still must understand what it does or you’re\njust replacing one set of problems with another set of more subtle\nproblems.\nFor example, we discussed earlier the importance of knowing\n\nwhen your destructor runs<\/a>.\nHere’s another example, courtesy of my colleague Chris Ashton.\nThis was posted\n\nas a Suggestion Box entry<\/a>,\nbut it’s pretty much a complete article on its own.\n<\/p>\n

\n

\nI came across an interesting bug this weekend\nthat I’ve never seen described anywhere else,\nI thought it might be good fodder for your blog.\n<\/p>\n

\nWhat do you suppose the following code does?\n<\/p>\n

\nCComBSTR bstr;\nbstr = ::SysAllocStringLen(NULL, 100);\n<\/pre>\n
    \n
  1. Allocates a BSTR<\/code> 100 characters long.\n
  2. Leaks memory and,\n    if you’re really lucky,\n    opens the door for an insidious memory corruption.\n<\/ol>\n
    \nObviously I’m writing here,\nso the answer cannot be A.  It is, in fact, B.\n<\/p>\n
    \nThe key is that CComBSTR<\/code> is involved here,\nso operator=<\/code> is being invoked.\nAnd operator=<\/code>, as you might recall,\ndoes a deep copy of the entire string,\nnot just a shallow copy of the BSTR<\/code> pointer.\nBut how long does operator=<\/code> think the string is?\nWell, since BSTR<\/code> and LPCOLESTR<\/code> are equivalent\n(at least as far as the C++ compiler is concerned),\nthe argument to operator=<\/code> is an LPCOLESTR<\/code> –\nso operator=<\/code> naturally tries to use the\nwcslen<\/code> length of the string,\nnot the SysStringLen<\/code> length.\nAnd in this case, since the string is uninitialized,\nwcslen<\/code> often returns a much smaller value than\nSysStringLen<\/code> would.\nAs a result, the original 100-character string is leaked,\nand you get back a buffer that can only hold, say, 25 characters.\n<\/p>\n
    \nThe code you really<\/i> want here is:\n<\/p>\n
    \nCComBSTR bstr;\nbstr.Attach(::SysAllocStringLen(NULL, 100));\n<\/pre>\n
    \nOr:\n<\/p>\n
    \nCComBSTR bstr(100);\n<\/pre>\n
    \nI’m still a big fan of smart pointers\n(surely the hours spent finding this bug\nwould have been spent finding memory leaks\ncaused by other incautious programmers),\nbut this example gives pause –\nCComBSTR<\/code> and some OLE calls just don’t mix.\n<\/p>\n<\/blockquote>\n
    \nAll I can add to this story is an exercise:\nChris writes,\n“Since the string is uninitialized,\nwcslen<\/code> often returns a much smaller value than\nSysStringLen<\/code> would.”\nCan it possibly return a larger<\/i> value?\nIs there a potential read overflow here?<\/p>\n","protected":false},"excerpt":{"rendered":"
    It’s great when you have a tool to make programming easier, but you still must understand what it does or you’re just replacing one set of problems with another set of more subtle problems. For example, we discussed earlier the importance of knowing when your destructor runs. Here’s another example, courtesy of my colleague Chris […]<\/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-21883","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
    It’s great when you have a tool to make programming easier, but you still must understand what it does or you’re just replacing one set of problems with another set of more subtle problems. For example, we discussed earlier the importance of knowing when your destructor runs. Here’s another example, courtesy of my colleague Chris […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/21883","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=21883"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/21883\/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=21883"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=21883"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=21883"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}