Who is responsible for putting the null terminator when handling TB_GETBUTTONTEXT?

The documentation for TB_GETBUTTONTEXT says that the handler has to return the number of characters and optiona开发者_Python百科lly (if lParam is not null) copy the string into the supplied buffer.

The caveat is that the length doesn't include the terminating character. I see the following problem. Say the handler stores the string precomputed (so its length doesn't change). First the caller sends the message with lParam set to null - to find the number of characters - and the handler returns the number of characters without the terminating null. Then the caller allocates memory and sends the message again - this time passing the buffer address as lParam.

Should the handler copy the terminating null? I mean if the first time the handler returned N and the caller allocated space for N characters and the handler appends a terminating null then buffer overrun occurs. But if the caller really expected the string to be null terminated and allocated space for N+1 characters and the handler doesn't append the null terminator the handler will have a string that is not null-terminated and again buffer overrun can occur (if the caller isn't careful enough).

So what should the handler do? Should it copy the null terminator or not?

---

MFC uses the sane approach in its CMFCToolBar::OnGetButtonText() implementation, it assumes the caller knows it should allocate N+1 and uses lstrcpy() to copy the text.