This is the mail archive of the
mailing list for the GCC project.
RE: FW: MAX_PATH problems with mingw gcc
- From: Vladimir Simonov <Vladimir dot Simonov at acronis dot com>
- To: Joey Ye <joey dot ye dot cc at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Jiri Dobry <jirik at kaznejov dot cz>
- Date: Thu, 17 Oct 2013 08:18:43 +0000
- Subject: RE: FW: MAX_PATH problems with mingw gcc
- Authentication-results: sourceware.org; auth=none
- References: <F0AD13EFC234B549BBA4FCA20755EB24CA7AF504 at rus-mbx-2 dot ru dot corp dot acronis dot com> <F0AD13EFC234B549BBA4FCA20755EB24D4210ABD at rus-mbx-2 dot ru dot corp dot acronis dot com> <CAL0py256Tyuc_JW5oAB66-WjnXhRT3N=OVtuecxETwh6-aVYDA at mail dot gmail dot com>
> -----Original Message-----
> From: Joey Ye [mailto:firstname.lastname@example.org]
> 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.
> 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
Thank you for pointing this problem.
So, on file systems with symlinks support "playing" with filenames as strings is impossible.
This means that filename_normalize name is too pretentious - it will do nothing for most of gcc consumers.
From other side - it is useful for OS-es with small MAX_PATH.
Do you think it should be renamed as filename_shortcut/filename_simplify or something like it?
So readers won't expect too much from it even without looking at its body.
Is it allowed to write
# ifdef HAVE_DOS_BASED_FILE_SYSTEM
extern void filename_normalize (char *f);
#define filename_normalize (char *f)
directly in include/filenames.h?
This way we'll avoid unnecessary empty call on platforms with symlinks.
And more common question.
I can imagine that different filenames produced after cross build on different OS-es for the same target
may confuse some upper-level tools, like code analyzers, code coverage, etc...
Does it make sense to push such solution to gcc mainsteam?
May be it is better to keep the patch for cross toolchains builders...