On Thu, Oct 17, 2013 at 4:18 PM, Vladimir Simonov <vladimir.simo...@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