277075 - Audit consumers of GetShortPathName

Status: NEW

(Core :: XPCOM, defect)

Description

[timeless]

(for lack of a better component)

Many consumers are using this function instead of properly quoting strings
before sending them to commandlines and other things.

note that GetShortPathName is not guaranteed to do something useful,
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/getshortpathname.asp

Return Values

If the function succeeds, the return value is the length, in TCHARs, of the
string copied to lpszShortPath, not including the terminating null character.

If the lpszShortPath buffer is too small to contain the path, the return value
is the size of the buffer, in TCHARs, required to hold the path. Therefore, if
the return value is greater than cchBuffer, call the function again with a
buffer that is large enough to hold the path.

If the function fails for any other reason, the return value is zero. To get
extended error information, call GetLastError.

Remarks

When an application calls this function and specifies a path on a volume that
does not support 8.3 aliases, the function fails with ERROR_INVALID_PARAMETER if
the path is longer than 67 bytes.

fwiw, winerror.h:#define ERROR_INVALID_PARAMETER     87

i believe most callers in our tree are broken.

for starters,
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/config/makedep.cpp&rev=1.9&mark=115#108
is wrong, if the function returns 2050 (which should be legal), then the code
happily copies an uninitialized buffer into a string and the caller has to use it.

for whomever adopts this bug, please try to replace code that uses this function
with code that doesn't need to use any function similar to this.

Comment 1

[Jim Mathies [:jimm]]

The only two callers I can find currently are xpcom and libpr0n, so I'm moving this to xpcom.

http://mxr.mozilla.org/mozilla-central/search?string=GetShortPathName