{"id":106870,"date":"2022-07-18T07:00:00","date_gmt":"2022-07-18T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106870"},"modified":"2022-07-18T06:39:19","modified_gmt":"2022-07-18T13:39:19","slug":"20220718-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220718-00\/?p=106870","title":{"rendered":"C++ coroutine gotcha: Falling off the end of a function-level catch"},"content":{"rendered":"

Allowing execution to flow off the end of a coroutine is equivalent to performing a co_return<\/code> with no operand, assuming the coroutine completes with no value. Otherwise, the behavior is undefined.<\/p>\n

This is the same rule as with regular functions, just with the letters “co” in front.<\/p>\n\n\n\n\n
\n
void f1()\r\n{\r\n    DoSomething();\r\n    \/\/ implicit \"return\"\r\n}\r\n<\/pre>\n<\/td>\n
\n
simple_task<void> f1co()\r\n{\r\n    co_await DoSomething();\r\n    \/\/ implicit \"co_return\"\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n
\n
int f2()\r\n{\r\n    DoSomething();\r\n    \/\/ illegal fall-of-the-end\r\n}\r\n<\/pre>\n<\/td>\n
\n
simple_task<int> f2co()\r\n{\r\n    co_await DoSomething();\r\n    \/\/ illegal fall-of-the-end\r\n}\r\n<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Unfortunately, many compilers (as of this writing) aren’t consistent in diagnosing this type of programming error.<\/p>\n
simple_task<int> f2co()\r\n{\r\n    co_await DoSomething();\r\n    \/\/ illegal fall-of-the-end\r\n}\r\n<\/pre>\n
\/\/ gcc 11.3 -std=c++20 -Wall\r\n(no errors or warnings)\r\n\r\n\/\/ clang 14.0.0 -std=c++20 -Wall\r\nwarning: non-void coroutine does not return a value\r\n\r\n\/\/ msvc 19.31 -std:c++20 -W4\r\nwarning C4033: 'f2co' must return a value\r\nnote: Flowing off the end of a coroutine results in undefined behavior when promise type 'std::coroutine_traits::promise_type' does not declare 'return_void'\r\n<\/pre>\n
In this case, clang and msvc notice that you forgot to return a value, but gcc doesn’t notice.<\/p>\n
If we tweak the function slightly, we get different results:<\/p>\n
simple_task<int> f3co()\r\n{\r\n    if (Maybe()) co_return 1;\r\n    \/\/ illegal fall-of-the-end\r\n}\r\n<\/pre>\n
\/\/ gcc 11.3 -std=c++20 -Wall\r\n(no errors or warnings)\r\n\r\n\/\/ clang 14.0.0 -std=c++20 -Wall\r\nwarning: non-void coroutine does not return a value in all control paths\r\n\r\n\/\/ msvc 19.31 -std:c++20 -W4\r\n(no errors or warnings)\r\n<\/pre>\n
Adding a co_return<\/code> on one branch of an if<\/code> statement is enough to fool msvc; it doesn’t notice that there’s still a code path that fails to co_return<\/code> something.<\/p>\n
And then there’s this wrinkle:<\/p>\n
simple_task<int> f4co() try\r\n{\r\n    co_return 1;\r\n}\r\ncatch (...)\r\n{\r\n    \/\/ illegal fall-of-the-end\r\n}\r\n<\/pre>\n
\/\/ gcc 11.3 -std=c++20 -Wall\r\n(no errors or warnings)\r\n\r\n\/\/ clang 14.0.0 -std=c++20 -Wall\r\nwarning: non-void coroutine does not return a value in all control paths\r\n\r\n\/\/ msvc 19.31 -std:c++20 -W4\r\n(no errors or warnings)\r\n<\/pre>\n
The catch<\/code> block fails to co_return<\/code> anything, which makes it an illegal fall-off-the-end, but gcc and msvc fail to detect it.<\/p>\n
This particular failure is easy to miss if you use the WIL exception handling macros like CATCH_LOG<\/code>:<\/p>\n
simple_task<int> f4co() try\r\n{\r\n    co_return 1;\r\n}\r\nCATCH_LOG(); \/\/ invisible fall-off-the-end\r\n<\/pre>\n
The CATCH_LOG<\/code> macro catches all exceptions, logs them through the WIL infrastructure, and then falls off the end of the function. It is intended to be used only in cases where falling off the end is allowed (namely, function returning void<\/code> or coroutine completing with void<\/code>). If you use it in a coroutine that has a completion value, then you will just fall off the end, and if you’re unlucky, the error will go undiagnosed, and you’re off in undefined territory.<\/p>\n
Bonus chatter<\/b>: But really, what happens when you fall off the end of the coroutine without co_return<\/code>ing a value? As I noted, it’s technically undefined behavior, but in practice what happens is that the promise’s return_value<\/code> method is never called before reaching final_suspend<\/code>. What happens next depends on how the promise is implemented.<\/p>\n
In our simple_task<\/code>, it means that the promise state remains empty<\/code>, and then when you try to co_await<\/code> the simple_task<\/code>,  the get_value<\/code> method hits an assertion failure and then forcibly std::terminate<\/code>s the program<\/a>.<\/p>\n
For PPL tasks, the promise implementation just returns a default-constructed result; For hat-types, that means a null pointer. For C++\/WinRT asynchronous operations, the promise implementation returns an empty result: For value types, you get a default-constructed value type; for reference types, you get a null pointer.<\/p>\n
This can lead to a good amount of head-scratching when you co_await<\/code> the task or asynchronous operation and get an empty result \/ null pointer even though you go back to the code and see that at no point does it ever co_return nullptr;<\/code>.<\/p>\n
From what you can tell, the compiler appears to have lost its mind, but really, you’re the one who went crazy. You just didn’t realize it.<\/p>\n","protected":false},"excerpt":{"rendered":"
You still have to return something, but today’s compilers don’t warn you.<\/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-106870","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
You still have to return something, but today’s compilers don’t warn you.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106870","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=106870"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106870\/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=106870"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106870"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106870"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}