#476 TFileName::Squeezed returns garbage for root folders

[Ognyan Chernokozhev]

TFileName::Squeezed, which calls TFileName::Title, which calls inside the Windows API function GetFileTitle, but does not check the return value in case the function fails.

This happens for example with root folders like c:\

[Ognyan Chernokozhev]

A quick fix is for TFileName::Title to check the return value of GetFileTitle and return empty string in this case. It solves the problem with TFileName::Squeezed, which is used by TRecentFiles, but any other users of that method should be aware that they would need to handle empty return strings.

[Ognyan Chernokozhev]

Fixed in trunk in [r5244].

[Vidar Hasfjord]

any other users of that method should be aware that they would need to handle empty return strings.

Fortunately, that is the documented behaviour for TFileName::Title since [r310], when the addition of a note about about returning null string was made. So this issue is simply an implementation bug, and checking the source, it is also present in OWL 5 (no initialisation of the buffer, and no checking of the return value from GetFileTitle).

However, note that the documentation says:

Returns null string for directory names or malformed names.

This is isn't quite accurate. I guess what is meant with "directory names" here is "paths ending with a backslash", or to be precise a TFileName object for which TFileName::HasParts (TPart::File) and HasParts(TPart::Ext) return false.

[Vidar Hasfjord]

Looks like there is another bug in TFileName::Title:

GetFileTitle(canonical.c_str(), tmp, sizeof tmp)

This fails in UNICODE build mode. The last argument should be the character count (see GetFileTitle documentation):

GetFileTitle(canonical.c_str(), tmp, COUNTOF(tmp))

Edit: This issue was fixed on the trunk in [r5246].

[Vidar Hasfjord]

The fixes for these issues have been merged into branches 6.44 [r5247] and 7.0 [r5249].

[Vidar Hasfjord]

Is this done? If so, change status to "pending" for release.