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 Thu, Oct 17, 2013 at 4:18 PM, Vladimir Simonov
<Vladimir.Simonov@acronis.com> wrote:
>
> 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);
> #else
> #define filename_normalize (char *f)
> #endif
> directly in include/filenames.h?
> This way we'll avoid unnecessary empty call on platforms with symlinks.
#define a lower case function name isn't a good practice. So please
resume your original change that define FILENAME_XXX here like:
#ifdef HAVE_DOS_BASED_FILE_SYSTEM
#define FILENAME_XXX(f) filename_xxx(f)
#else
#define FILENAME_XXX(f)
#endif
>
> 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...
IMO it is not a concern. One reason libiberty is there, is because
people know different OS-es have different filename system. A tool
should either use libiberty to process it, or smarter enough to handle
difference by themselves.

Another good thing about the idea of filename_normalize is that it
make possible to do real filename_cmp. Current filename_cmp fails to
compare c:/a/b/.. and c:/a. You patch is at least a start to solve it.

I do encourage you to upstream this patch, though I'm not the
maintainer of libiberty to approve it.

Thanks,
Joey


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