there is not a problem in TPath.GetXXX ?

there is not a problem in TPath.GetXXX ?

like this one 

class function TPath.GetDownloadsPath: string;
var
  LStr: array[0 .. MAX_PATH] of Char;
begin
  SetLastError(ERROR_SUCCESS);
  if SHGetFolderPath(0, CSIDL_LOCAL_APPDATA, 0, 0,@LStr)= S_OK then
    Result := LStr;
end;

Result is not initialized on a SHGetFolderPath error.

Comments

  1. MSDN:
    "A pointer to a null-terminated string of length MAX_PATH which will receive the path. If an error occurs or S_FALSE is returned, this string will be empty. The returned path does not include a trailing backslash. For example, "C:\Users" is returned rather than "C:\Users\"."
    In every case LStr will be filled with valid information so no need of extra initialization.

    ReplyDelete
  2. Result is initialized automatically to an empty string (nil), because it is a refcounted object and all refcounted objects must be initialized (otherwise the compiler cannot refcount them),

    ReplyDelete
  3. Primož Gabrijelčič That is not correct. Result is what you are assigning this function to - remember managed types are passed as hidden var parameter.

    so, if you write this

    var
      s: string;
    begin  
      s := 'oh damn!';
      s := TPath.GetDownloadsPath;

    and GetDownloadsPath had an error in SHGetFolderPath, s still contains 'oh damn!'

    because the compiler in fact translates this method to:

    class procedure TPath.GetDownloadsPath(var Result: string);

    and the call to
    TPath.GetDownloadsPath(s);

    FixInsight would complain on this method with "W521 Return value of function 'GetDownloadsPath' might be undefined" (what actually the compiler should do).

    Also the documentation for TPath.GetDownloadsPath says:
    "If the system running your application does not support the requested folder, or if the requested folder does not exist in the system, this function returns an empty string instead." which is clearly wrong

    In the comments to this post (https://plus.google.com/+StefanGlienke/posts/S9wdCNMi6EW) Allen Bauer explained why this is not an easy fix.

    ReplyDelete
  4. Fabian S. Biehn  It is Result that is not assigned to

    ReplyDelete
  5. Ooops, I stand corrected. Stefan Glienke , thanks!

    ReplyDelete

Post a Comment