Old _fullpath bug: time to fix it in new VC release?

The C runtime function _fullpath has a very annoying behavior that seems to exist thru VS.2005 RTM. I'd call it a bug... anyway, would be great to see it fixed some day.

How it works today: 
 - if the path is relative, it does GetCurrentDirectory into the output buffer
 - then it appends source path to output buffer.
    If the result > MAX_PATH, it fails.
 - then it resolves any . and .. in the buffer.

This means that even if the resulting path is much shorter than MAX_PATH,
the intermediate append of current path can cause failure.

Suppose the source string is 200 chars long and current directory is 70,
this gives 270 and will fail even if the resulting string 
(after resolving all .. ) is short.

What is a possible fix:

 - if the path is relative, allocate temporary buffer of length = 
 length of source buffer + MAX_PATH;
GetCurrentDirectory into the temp buffer;
append source path to temp buffer.

Then continue as usual. At end, release the temp buffer.

Allocation of a temp buffer is very cheap, compared to all the garbage collection stuff - something you definitely can afford in VS2005.

Note that WinCE has API CeGetCanonicalPath, but the "big" Windows has only this runtime function.

Regards,
--PA



Answer this question

Old _fullpath bug: time to fix it in new VC release?

  • RamaGudimetla

    Oops. I've found the corresponding Windows API: GetFullPathName.
    And it has almost same behavior :(
    So, fixing the C runtime function will make it not consistent with the API :((  Well, anyway I'll try to post a suggestion.

    --PA

  • JonathanV

    Hi Pavel,
      Could you please log the issue and your suggested fix at http://lab.msdn.microsoft.com/productfeedback/ I am sure the owners would love to have a look.

    Thanks in advance for taking the time to enter the issue!

    Thanks,
      Ayman Shoukry
      VC++ Team



  • Old _fullpath bug: time to fix it in new VC release?