This is the mail archive of the
gcc-patches@gcc.gnu.org
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 09:13:27 +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> <CAL0py24X-oLdjNgLOWQhWTLSi0-anf1wp1aSrkJ=e41zGzwWag at mail dot gmail dot com>
Thank you for review. Please see inline
> From: Joey Ye [mailto:joey.ye.cc@gmail.com]
> Sent: Thursday, October 17, 2013 7:36 AM
>
> The macro FILENAME_NORMALIZE doesn't look necessary. I would prefer use filename_normalize directly, just as filename_cmp is used in GCC rather than FILENAME_CMP
The patch is quite old(from gcc 4.2, may be 4.3). As I remember those days filenames.h had only
extern int filename_cmp (const char *s1, const char *s2);
#define FILENAME_CMP(s1, s2) filename_cmp(s1, s2)
at the end. So I just followed its style. Nowadays the style is changed.
I'll use filename_normalize everywhere.
>
>
> Also it normalize filename like:
> c:\abc\ into c:/abc\
>The ending \ isn't normalized. Need to refine logic here to handle this case.
Thank you.
I was concentrated on filenames "shorting" correctness and missed this case.
In fact it is not too bad - the patch doesn't guarantee that all filenames inside gcc process will be
as short as possible and will have forward slashes. It just simplifies filenames in some key places.
Anyway, I'll add this case to my test and fix it.
Other comments are accepted without notes:)
I'll redo the patch in several days.
Thank you
Vladimir