This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: FW: MAX_PATH problems with mingw gcc


On Wed, Oct 16, 2013 at 6:45 PM, Vladimir Simonov
<Vladimir.Simonov@acronis.com> wrote:
> There are many pro and contras, i.e. it adds additional, probably unnecessary work on Linux
> time but makes filenames shorter, it affects libiberty which is shared between gcc/binutils/gdb,
> but it may be useful in other packages, etc.,
> etc.
There is an issue on file system with symbolic link, like Linux
ext2/3. It could vitally change behavior of GCC. The issue is
described as following.

Given that on Linux you have following directory structure:

base/
       level1-a/
                  level2-a/
       level2-b (-> level1-a/level2-a)

level2-b is a symbolic link created by:
ln -s level1-a/level2-a level1-b

Now run "ls base/level2-b/.." you probably would expect it equal to
"ls base", as the logic in your patch implies. However, the actual
behavior is equal to "ls base/level1-a" instead, because
base/level2-b/.. == base/level1-a/level2-a/.. == base/level1-a

Such a logic cannot be deduced simple from the name string, so your
patch can do nothing about it.

For your patch IMHO the way out could be just define a real function
for DOS FS, and leave a blank function body otherwise. Like:
filename_normalize (char *fn)
{
#if DOS
...
#endif
}

Thanks,
Joey


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]