RE: FW: MAX_PATH problems with mingw gcc

[Vladimir Simonov <Vladimir dot Simonov at acronis dot com>]

> -----Original Message-----
> From: Joey Ye [mailto:joey.ye.cc@gmail.com] 
> 
> 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
> ...
> #endif
> }

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. 

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...

Regards
Vladimir