This is the mail archive of the 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

> -----Original Message-----
> From: Joey Ye [] 
> 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
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...


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