{"id":110681,"date":"2024-12-27T07:00:00","date_gmt":"2024-12-27T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110681"},"modified":"2025-01-03T11:53:33","modified_gmt":"2025-01-03T19:53:33","slug":"20241227-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20241227-00\/?p=110681","title":{"rendered":"In C++, failure to meet the requirements does not always mean that you fail if you don’t meet the requirements"},"content":{"rendered":"

I was asked to help debug a problem where a pointer passed to a function was received slightly offset from the original value. The pointer is passed as an opaque parameter and is supposed to be spit out the other end of a pipeline. But somehow, the value that came out the other end was slightly different.<\/p>\n

For expository purposes, let’s say that the underlying function we’re trying to call is this one.<\/p>\n

void SubmitWork(HWORKER worker, int commandCode, void* param);\r\n<\/pre>\n
You call Submit\u00adWork<\/code> with a worker, a command code, and a raw pointer to some data that depends on the command code.<\/p>\n
The developer sent me some debugging output that showed that the function that handled the command code received a different pointer from what was passed. One possibility is that there was a bug in the library that resulted in it unintentionally modifying the final pointer parameter, but this seemed unlikely, since the value should be opaque to the library. I was able to get on a video call with the developer to watch them step through the code, and that’s where I noticed something interesting.<\/p>\n
The developer’s code didn’t actually call Submit\u00adWork<\/code>, but rather used a wrapper that in turn called Submit\u00adWork<\/code>:<\/p>\n
class Worker\r\n{\r\npublic:\r\n    void SubmitWork(int commandCode, void* param)\r\n    {\r\n        ::SubmitWork(m_worker, commandCode, param);\r\n    }\r\n\r\n    template<typename T>\r\n    void SubmitWork(int commandCode, T& param)\r\n        requires std::is_standard_layout_v<T>\r\n    {\r\n        \/\/ Delegate to the void* version.\r\n        SubmitWork(commandCode, std::addressof(param));\r\n    }\r\nprivate:\r\n    HWORKER m_worker;\r\n};\r\n<\/pre>\n
The wrapper is trying to make the Submit\u00adWork()<\/code> function a little easier to use by letting you pass a standard layout type as the second parameter, and it will pass it by address. The idea is that in addition to passing a raw pointer, you can also pass a structure like this:<\/p>\n
struct SetSizeInfo\r\n{\r\n    uint64_t itemId;\r\n    uint64_t size;\r\n};\r\nSetSizeInfo info;\r\ninfo.itemId = 31415;\r\ninfo.size = 64;\r\nworker.SubmitWork(CMD_SETSIZE, info);\r\n<\/pre>\n
and it turns into<\/p>\n
::SubmitWork(m_hWorker, CMD_SETSIZE, &info);\r\n<\/pre>\n
with an extra check that info<\/code> is a standard layout type (can be memcpy<\/code>‘d).<\/p>\n
But it turns out that this helper isn’t so helpful.<\/p>\n
Suppose you had someone who called the method the old-fashioned pointer way:<\/p>\n
char* name = allocate_name();\r\nworker.SubmitWork(CMD_SETNAME, name);\r\n<\/pre>\n
The compiler sees that both of the overloads of the Submit\u00adWork<\/code> method are in play.<\/p>\n
\/\/ Using conversion from char*& to void*\r\nworker.SubmitWork(int, void*);\r\n\r\n\/\/ Treating the char* as a standard layout type.\r\nworker.SubmitWork<char*>(int, char*&);\r\n<\/pre>\n
The second overload is in play because pointers are standard layout types.<\/p>\n
And the second overload wins because char*&<\/code> is a better match for char*&<\/code> than void*<\/code>!<\/p>\n
This means that instead of passing the pointer through to ::Submit\u00adWork()<\/code>, the templated helper function passes the address of<\/i> the pointer to ::Submit\u00adWork()<\/code>.<\/p>\n
And that’s why the pointer arrives incorrectly when the work is processed: The pointer that was passed to ::Submit\u00adWork<\/code> was correctly passed through to the processor. The problem is that the wrong pointer was passed to ::Submit\u00adWork<\/code> in the first place!<\/p>\n
One way to fix this is to make pointers ineligible for the template function.<\/p>\n
    template<typename T>\r\n    void SubmitWork(int commandCode, T& param)\r\n        requires std::is_standard_layout_v<T>\r\n        && (!std::is_pointer_v<T>)\r\n    {\r\n        \/\/ Delegate to the void* version.\r\n        SubmitWork(commandCode, std::addressof(param));\r\n    }\r\n<\/pre>\n
However, this approach still has a hole:<\/p>\n
std::string name(\"hello\");\r\nworker.SubmitWork(CMD_SETNAME, &name);\r\n<\/pre>\n
Here, I am passing a pointer to a non-standard-layout type, and since the template function is not eligible for pointers, the only remaining overload is the one that takes a void*<\/code>, which std::string*<\/code> happily converts to.<\/p>\n
The helpers were trying to make sure that only pointers to standard layout types are passed to ::Submit\u00adWork<\/code>, but I was able to sneak a std::string*<\/code> into ::Submit\u00adWork<\/code> because the template function that did the enforcement removed itself from consideration<\/i> rather than accepting the parameter and then complaining about it.<\/p>\n
In C++, if the compiler is unable to satisfy the constraints of a function, the function is simply ignored<\/i> and not considered for overload resolution. You sort of knew that: Suppose you have two overloads of the do_something()<\/code> function:<\/p>\n
void do_something(char* p);\r\nvoid do_something(int v);\r\n<\/pre>\n
When you write do_something(42)<\/code>, the first overload is ignored because 42<\/code> cannot be converted to char*<\/code>, and the second overload is used because 42<\/code> can indeed be converted to int<\/code>. You did not expect to get an error from the char*<\/code> overload.<\/p>\n
But in our case with Submit\u00adWork()<\/code>, if you call it with a pointer to a non-standard-layout type, we don’t want the template version to be ignored. We want it to trigger an error! But it doesn’t, because it is a failed substitution, and as we all know, Substitution Failure Is Not An Error (SFINAE). What we want to do is to allow the substitution to succeed, but then generate an error in the function body if the type is not standard layout.<\/p>\n
    \/\/ Basic version, no extra checking.\r\n    void SubmitWork(int commandCode, void* param)\r\n    {\r\n        ::SubmitWork(m_worker, commandCode, param);\r\n    }\r\n\r\n    \/\/ This version matches all non-void pointers.     <\/span>\r\n    template<typename T>                               <\/span>\r\n    void SubmitWork(int commandCode, T* param)         <\/span>\r\n    {                                                  <\/span>\r\n        static_assert(std::is_standard_layout_v<T>,    <\/span>\r\n            \"T must be a standard layout type\");       <\/span>\r\n        \/\/ Delegate to the void* version.              <\/span>\r\n        SubmitWork(commandCode,                        <\/span>\r\n            static_cast<void*>(param));                <\/span>\r\n    }                                                  <\/span>\r\n    \u00a0                                                  <\/span>\r\n    \/\/ This overload matches all references.           <\/span>\r\n    template<typename T>                               <\/span>\r\n    void SubmitWork(int commandCode, T& param)         <\/span>\r\n    {                                                  <\/span>\r\n        \/\/ Delegate to the T* version.                 <\/span>\r\n        SubmitWork(commandCode, std::addressof(param));<\/span>\r\n    }                                                  <\/span>\r\n<\/pre>\n
In my opinion, taking a reference just adds to the confusion. I took the solution a step further and got rid of the reference overload. Everybody just calls with the pointer they want to submit.<\/p>\n
    \/\/ Basic version, no extra checking.\r\n    void SubmitWork(int commandCode, void* param)\r\n    {\r\n        ::SubmitWork(m_worker, commandCode, param);\r\n    }\r\n\r\n    \/\/ This version matches all non-void pointers.     <\/span>\r\n    template<typename T>                               <\/span>\r\n    void SubmitWork(int commandCode, T* param)         <\/span>\r\n    {                                                  <\/span>\r\n        static_assert(std::is_standard_layout_v<T>,    <\/span>\r\n            \"T must be a standard layout type\");       <\/span>\r\n        \/\/ Delegate to the void* version.              <\/span>\r\n        SubmitWork(commandCode,                        <\/span>\r\n            static_cast<void*>(param));                <\/span>\r\n    }                                                  <\/span>\r\n\r\n    \/\/ This overload matches all references.<\/span>\r\n    \/\/ template<typename T><\/span>\r\n    \/\/ void SubmitWork(int commandCode, T& param)<\/span>\r\n    \/\/ {<\/span>\r\n    \/\/     \/\/ Delegate to the T* version.<\/span>\r\n    \/\/     SubmitWork(commandCode, std::addressof(param));<\/span>\r\n    \/\/ }<\/span>\r\n<\/pre>\n
This avoids confusion over whether passing a pointer means “I’m calling it with the pointer I want”, or whether it means “I’m calling it with a standard layout type that happens to be a pointer!” (so please pass a pointer to it).<\/p>\n
In fact, you can go even further and get rid of the overload!<\/p>\n
    \/\/ Basic version, no extra checking.<\/span>\r\n    \/\/ void SubmitWork(int commandCode, void* param)<\/span>\r\n    \/\/ {<\/span>\r\n    \/\/     ::SubmitWork(m_worker, commandCode, param);<\/span>\r\n    \/\/ }<\/span>\r\n\r\n    template<typename T>\r\n    void SubmitWork(int commandCode, T* param)\r\n    {\r\n        static_assert(std::is_same_v<T, void> ||   <\/span>\r\n                      std::is_standard_layout_v<T>,<\/span>\r\n            \"T must be a standard layout type\");\r\n        ::SubmitWork(m_worker, commandCode, param));\r\n    }\r\n<\/pre>\n
Now there is no confusion over which overload you are calling because there is no longer an overload.<\/p>\n","protected":false},"excerpt":{"rendered":"
Combining SFINAE\/requires, standard layout, and overload resolution.<\/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-110681","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Combining SFINAE\/requires, standard layout, and overload resolution.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110681","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=110681"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110681\/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=110681"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110681"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110681"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}