{"id":112025,"date":"2026-01-30T07:00:00","date_gmt":"2026-01-30T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=112025"},"modified":"2026-01-30T15:02:46","modified_gmt":"2026-01-30T23:02:46","slug":"20260130-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20260130-00\/?p=112025","title":{"rendered":"Why not store the SAFEARRAY<\/CODE> reference count as a hidden allocation next to the SAFEARRAY<\/CODE>?"},"content":{"rendered":"

When I described how Safe\u00adArray\u00adAdd\u00adRef<\/code> keeps its reference count in a side table<\/a>, commenter Koro Unhallowed wondered why we couldn’t store the reference count either before or after the formal SAFEARRAY<\/code> structure<\/a>. Commenter Peter Cooper Jr. suspected that there might be cases where applications assumed how much memory a SAFEARRAY<\/code> occupied<\/a>.<\/p>\n

And indeed that is the case.<\/p>\n

Not all SAFEARRAY<\/code>s are created by the Safe\u00adArray\u00adCreate<\/code> function. I’ve seen code that declared and filled out their own SAFEARRAY<\/code> structure. In those cases, the code allocates exactly sizeof(SAFEARRAY)<\/code> bytes and doesn’t allocate any bonus data for the reference count.<\/p>\n

Indeed, there three flags in the fFeatures<\/code> member<\/a> for these “bring your own SAFEARRAY<\/code>” structures.<\/p>\n\n\n\n\n\n
FADF_AUTO<\/code><\/td>\nAn array that is allocated on the stack.<\/td>\n<\/tr>\n
FADF_STATIC<\/code><\/td>\nAn array that is statically allocated.<\/td>\n<\/tr>\n
FADF_EMBEDDED<\/code><\/td>\nAn array that is embedded in a structure.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These flag indicate that the array was not created by Safe\u00adArray\u00adCreate<\/code> but rather was constructed manually by the caller in various ways.\u00b9<\/p>\n

Note that if you pass a SAFEARRAY<\/code> with one these flags to Safe\u00adArray\u00adAdd\u00adRef<\/code>, it will still increment the reference count, but you don’t get a data pointer back because the caller does not control the lifetime of the SAFEARRAY<\/code>. The lifetime of the SAFEARRAY<\/code> is controlled by the lifetime of the SAFEARRAY<\/code> variable on the stack (FADF_AUTO<\/code>), in the DLL’s global data segment (FADF_STATIC<\/code>), or in the enclosing object (FADF_EMBEDDED<\/code>).<\/p>\n

This means that our earlier suggestion to wrap the SAFEARRAY<\/code> inside an in\/out VARIANT<\/code> runs into trouble if the SAFEARRAY<\/code> is one of these types of arrays with externally-controlled lifetime. For those, you have no choice but to copy the data.<\/p>\n

\u00b9 The documentation is, however, ambiguous about what “the array” refers to. Is it referring to the SAFEARRAY<\/code> structure itself? Or is it referring to the data pointed to by the pvData<\/code> member?<\/p>\n","protected":false},"excerpt":{"rendered":"

The case of “Bring your own SAFEARRAY<\/CODE>.”<\/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-112025","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"

The case of “Bring your own SAFEARRAY<\/CODE>.”<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112025","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=112025"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/112025\/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=112025"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=112025"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=112025"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}