Pesky LPCWSTR pointers!

This should work (untested):

Thanks, I was working on it way too late :)

How is declaring a character buffer a possible overrun?

No data type is inherently a possible buffer overrun, and every type used improperly could be a 'buffer overrun' (quoted since copying memory into say, an int variable isn't a buffer).

It's the way buffers (most notably string buffers) are used that cause overruns, and just getting into the habit of doing some things can prevent that. Such things can include, setting the last value in the buffer to null (before and not overwriting it, or after). It's a matter of preference, but I like to Zero my buffers and then use them by their size minus one, such as:

char szBuffer[256];ZeroMemory( szBuffer, sizeof( szBuffer ) / sizeof( *szBuffer ));DoSomeCopyOperation( szBuffer, sizeof( szBuffer ) / sizeof( *szBuffer ) - 1 );

DoSomeCopyOperation in this case takes a count of chars, as opposed to a count of bytes (which would be sizeof( szBuffer ) - sizeof( *szBuffer )).

Why use sizeof? Pragmatism. If you used hard values in all your functions that use szBuffer, you need to change them all if you change the size of szBuffer.

Why the '/ sizeof( *szBuffer )'? If you changed char to WCHAR (or the deprecated TCHAR - opinion based on unicows usage), again, the arguments would need no changes. I personally use a macro SizeOfString which is just the sizeof/sizeof set so it doesn't look so scary : )

-Alamar

Quote:

Original post by Alamar How is declaring a character buffer a possible overrun?

Well, if you had that code in a function that can take any length of input string, and you pass a string of > 255 characters, you're likely to get a buffer overrun. WideCharToMultiByte() needs to know the buffer length, but it may not NULL terminate it if it was to overflow (I don't know if it actually does). In the best case, you'll lose the end of your string. In the worst case, it won't be NULL terminated, and you'll run into all sorts of weird problems. Of course that can be solved by adding szText[255] = '\0'; though.
Overall, you should probably dynamically allocate memory in that function, instead of assuming that it won't ever recieve a buffer over 255 characters long.