Sorry, i still don't understand the need to manually strip the terminating #0, you could simply use this
Code:
class function TForm25.GetShortName(Filename: string): string;
var
Len: Integer;
begin
Len := GetShortPathName(PChar(Filename), nil, 0);
SetLength(Result, Len);
Len := GetShortPathName(PChar(Filename), PChar(Result), Len);
SetLength(Result, Len);
Result := Trim(Result); // will remove terminating #0s if there is any
end;
I am also not a fan of juggling strings, but with two line of Pascal the compiler is producing very close instructions as longer and more readable suggested above, so no real performance degradation, on other hand the lack of "const Filename: string" have more impact performance wise.
One more thing, once the data (aka string in this case) is in the Delphi/Pascal string realm there is no reason to keep the terminating #0, on the contrary it is more concise to strip them with Trim().
After that if you want to check or validate the result then use FileExist or any equivalent.
Also i want to point to the fact with -1 in the code in previous post, there was an overflow with one char, this is hidden with FastMM and even EurekaLog might fail to detect such small overflow because it is smaller than 32bit, (rare cases but there are there specially with strings do the in consistency in
RTL, strings and reserve #0), but i can imagine cases with specific length where the length is a multiplication of specific n (n= 4, 8, 16..) and your code did call some allocation after getting the paths, next allocation was also a string and it was empty, causing to fill the last char with 0 in your path/file name, this can explain the successful result most the time but not every time and also explain the difficulty in reproducing, so try to replicate your test with exact path and file length, don't use arbitrary, or go with full brut force from the shortest to longest and see if or when it will fail reliably.