{"id":110744,"date":"2025-01-10T07:00:00","date_gmt":"2025-01-10T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=110744"},"modified":"2025-01-10T09:57:57","modified_gmt":"2025-01-10T17:57:57","slug":"20250110-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20250110-00\/?p=110744","title":{"rendered":"Why does inadvertently passing a std::string<\/CODE> instead of a char const*<\/CODE> to a variadic function crash on x86-32 but not x86-64?"},"content":{"rendered":"

A customer tracked down a crash to inadvertently passing a std::string<\/code> instead of a char const*<\/code> to a variadic function.<\/p>\n

extern void Log(const char* format, ...);\r\n\r\nstd::string name(\"apple\");\r\n\r\nLog(\"%z: %d\", name, 42); \r\n\/\/ oops, should be Log(\"%z: %d\", name.c_str(), 42);\r\n<\/pre>\n
The Log<\/code> function takes a format string similar to printf<\/code>, but with slightly different insertions. In this case, it uses %z<\/tt> to represent a null-terminated string. (Other formats include %v<\/tt> for std::string_view<\/code>.)<\/p>\n
As noted in the comment, the name<\/code> parameter should have been passed as name.c_str()<\/code> so that a const char*<\/code> is passed, which is what %z<\/tt> expects.<\/p>\n
The customer found something unusual in the failure profile: Only the x86-32 systems were crashing. The x86-64 systems were working fine. What’s going on?<\/p>\n
The C++ language specifies that implementations are permitted but not required to support passing class types to satisfy a classic C-style ...<\/code> argument.\u00b9 The clang and gcc compilers do not allow it, but msvc does. What is it about x86-32 that makes the code crash, and what is it about x86-64 that makes it work?<\/p>\n
The calling convention for x86-32 passes parameters on the stack by value, so there is a std::string<\/code> on the stack after the format string. On the other hand, the calling convention for x86-64  passes large structures by address<\/a>. The 64-bit std::string<\/code> is 32 bytes in msvc, so it will be passed by address.<\/p>\n
The other piece of information you need to know to understand what’s going on is the internal layout of a std::string<\/code> in msvc,  which we studied some time ago<\/a>.<\/p>\n
Now let’s put things together.<\/p>\n
In the case above, the string \"apple\"<\/tt> fits inside the 16-character short string buffer, so in the 32-bit case, the values on the stack are the characters of the string, followed by the size and capacity.<\/p>\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n <\/td>\n42<\/td>\n<\/tr>\n
std::string<\/tt><\/span><\/td>\n\u00a0<\/td>\ncapacity<\/td>\n<\/tr>\n
size<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
e<\/tt><\/td>\n\\0<\/tt><\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
a<\/tt><\/td>\np<\/tt><\/td>\np<\/tt><\/td>\nl<\/tt><\/td>\n<\/tr>\n
 <\/td>\n <\/td>\npointer<\/td>\n\u2192 \"%z: %d\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Now we can see why the code crashes on x86-32: The Log<\/code> function interprets the stack like this:<\/p>\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n42<\/td>\n<\/tr>\n
 <\/td>\ncapacity<\/td>\n<\/tr>\n
 <\/td>\nsize<\/td>\n<\/tr>\n
 <\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
 <\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
int<\/tt><\/td>\ne<\/tt><\/td>\n\\0<\/tt><\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
const char*<\/tt><\/td>\na<\/tt><\/td>\np<\/tt><\/td>\np<\/tt><\/td>\nl<\/tt><\/td>\n<\/tr>\n
const char*<\/tt><\/td>\npointer<\/td>\n\u2192 \"%z: %d\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The first four characters of the string are misinterpreted as a pointer, resulting in an invalid pointer that crashes when the Log<\/code> function tries to treat it as a pointer to a string. (It crashes before getting around to the garbage integer parameter coming next.)<\/p>\n
On the other hand, on x86-64, the std::string<\/code> is passed by address, so you get this:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
std::string<\/tt><\/span><\/td>\n\u00a0<\/td>\ncapacity<\/td>\n<\/tr>\n
size<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
a<\/tt><\/td>\np<\/tt><\/td>\np<\/tt><\/td>\nl<\/tt><\/td>\ne<\/tt><\/td>\n\\0<\/tt><\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u22ee<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 3)<\/td>\nr9<\/tt> = ?<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 2)<\/td>\nr8<\/tt> = 42<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 1)<\/td>\nrdx<\/tt> \u2192 std::string<\/tt> on stack<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 0)<\/td>\nrcx<\/tt> \u2192 \"%z: %d\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
In the x86-64 case, the value in rdx<\/code> is treated as a pointer to a null-terminated string, and how about that, it is! It points to the \"apple\"<\/tt> stored in the short string buffer. Next is the value in r8<\/code>, which is treated as the integer parameter, and that’s what it is too!<\/p>\n
So that’s why the problem doesn’t appear on x86-64: The short string optimization, the policy of passing large structures by address, and the specific layout of a std::string<\/code> in msvc collectively mean that a pointer to a short std::string<\/code> also works as a pointer to a null-terminated string because the null-terminated string is at the start of the std::string<\/code>.<\/p>\n
The customer explained that in all the cases they know about, the name is a relatively short string, just 5 to 10 characters. This means that it will always fit in the short string buffer, and the above diagrams will apply.<\/p>\n
But what if the name doesn’t fit in the short string buffer?<\/p>\n
In the x86-32 case, we get this:<\/p>\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n <\/td>\n42<\/td>\n<\/tr>\n
std::string<\/tt><\/span><\/td>\n\u00a0<\/td>\ncapacity<\/td>\n<\/tr>\n
size<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
pointer<\/td>\n\u2192 \"relatively long name\"<\/tt><\/td>\n<\/tr>\n
 <\/td>\n <\/td>\npointer<\/td>\n\u2192 \"%z: %d\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
If we relabel the parameters by how the Log<\/code> function sees them:<\/p>\n\n\n\n\n\n\n\n\n\n\n
 <\/td>\n42<\/td>\n<\/tr>\n
 <\/td>\ncapacity<\/td>\n<\/tr>\n
 <\/td>\nsize<\/td>\n<\/tr>\n
 <\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
 <\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
int<\/tt><\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
const char*<\/tt><\/td>\npointer<\/td>\n\u2192 \"relatively long name\"<\/tt><\/td>\n<\/tr>\n
const char*<\/tt><\/td>\npointer<\/td>\n\u2192 \"%z: %d\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
This time, the Log<\/code> function reads the first four bytes of the std::string<\/code>, and they are a pointer to the string data, so the string gets logged succssfully. However, the integer value is not the expected value of 42, but rather four garbage bytes from the unused portion of the small string buffer inside the std::string<\/code>.<\/p>\n
If you have a large string on x86-64, you get this:<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
std::string<\/tt><\/span><\/td>\n\u00a0<\/td>\ncapacity<\/td>\n<\/tr>\n
size<\/td>\n<\/tr>\n
?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/tr>\n
pointer<\/td>\n\u2192 \"relatively long name\"<\/tt><\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n\u22ee<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 3)<\/td>\nr9<\/tt> = ?<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 2)<\/td>\nr8<\/tt> = 42<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 1)<\/td>\nrdx<\/tt> \u2192 std::string<\/tt> on stack<\/td>\n<\/tr>\n
 <\/td>\n <\/td>\n(home space 0)<\/td>\nrcx<\/tt> \u2192 \"%z: %d\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
This time, the Log<\/code> function interprets rdx<\/code> as a pointer to a null-terminated string, and it ends up interpreting the bytes of the pointer at the start of the std::string<\/code> as characters to be logged, so you will get garbage. If you assume that even a long name won’t be 4 billion characters long, then you know that the garbage will find a null byte within 20 characters, because it’ll eventually run into the zeroes that form the most significant bytes of the size<\/code>. The integer value in r8<\/code> is interpreted as intended.<\/p>\n
Okay, so here’s what we have:<\/p>\n\n\n\n\n\n
\u00a0<\/th>\nx86-32<\/th>\nx86-64<\/th>\n<\/tr>\n
Short name<\/th>\n(crash)<\/td>\n\"name: value\"<\/tt><\/td>\n<\/tr>\n
Long name<\/th>\n\"name: garbage\"<\/tt><\/td>\n\"garbage: value\"<\/tt><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
The customer used these results to prioritize how urgently a fix is needed for the two platforms. They decided that the x86-32 version required an immediate fix, but the x86-64 version could wait, since the only consequence is garbage in a log file. They’ll just make a note in their debugging documents that the name in the 64-bit log file is not trustworthy for this particular version of their program.<\/p>\n
\u00b9 Not to be confused with a C++-style template parameter pack.<\/p>\n","protected":false},"excerpt":{"rendered":"
Looking at the calling convention and the small string optimization.<\/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-110744","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
Looking at the calling convention and the small string optimization.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110744","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=110744"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/110744\/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=110744"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=110744"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=110744"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}