Does SHGetPathFromIDList() (and similar) put a terminating 0 in its argument?

Question

This is actually a question about a huge number of winapi functions. A typical MS documentation says (from http://msdn.microsoft.com/en-us/library/bb762194%28VS.85%29.aspx ):

BOOL SHGetPathFromIDList(      
    PCIDLIST_ABSOLUTE pidl,
    LPTSTR pszPath
);

pidl [in] The address of an item identifier list that specifies a file
or directory location relative to the root of the namespace (the desktop).

pszPath [out] The address of a buffer to receive the file system path.
This buffer must be at least MAX_PATH characters in size.

Nowhere does it say about whether a terminating 0 is written to pszPath. Also, it doesn't say whether the path can fill the pszPath, leaving no room for 0 there.

Googling around yeidls about 50/50 distribution of users who allocate a buffer with MAX_PATH+1 chars and users who only deal with MAX_PATH.

While I can certainly do something like char buf[MAX_PATH+1]={0} to be on the safe side, I would really like to know - is there some place where this stuff is described? Some page for all path-related functions maybe, I don't know...

Answer 1

I don't know how this function (or the others) actually behaves, but I'd recommend writing a few unit tests against this function... What happens when you don't use all of the buffer? What happens if you do? etc. Not only will these document your assumptions, but if the function ever changes how it behaves, you'll get a warning from your unit tests instead of experiencing a nasty bug report coming in.

Answer 2

It says "This buffer must be at least MAX_PATH characters in size" for pszPath parameter so MAX_PATH buffer size should be always enough. Also I believe that all Win32 functions dealing with LPCTSTR / LPTSTR parameters expect or return null-terminated strings.

Answer 3

To answer the title question: Yes. It's part of the definition of LPTSTR - a pointer to a string. It is also reflected in the prefix: psz - "Pointer (to) String (terminated by) Zero".

There is a non-null-terminated stringtype as well, but it's rare in userland API's: UNICODE_STRING. You see it mostly in kernel-level APIs