From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31267 invoked by alias); 25 Apr 2014 19:24:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31253 invoked by uid 89); 25 Apr 2014 19:24:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Apr 2014 19:24:06 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3PJO3jc013310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Apr 2014 15:24:04 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3PJO00s008218; Fri, 25 Apr 2014 15:24:01 -0400 Message-ID: <535AB650.1080102@redhat.com> Date: Fri, 25 Apr 2014 19:35:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Kai Tietz CC: Kai Tietz , Ray Donnelly , GCC Patches , Kai Tietz Subject: Re: [PATCH 2/2] Windows libcpp: Make path-exists semantics more Posix-like References: <1397936424-2290-1-git-send-email-mingw.android@gmail.com> <1397936424-2290-3-git-send-email-mingw.android@gmail.com> <1034557352.9542218.1397940098399.JavaMail.zimbra@redhat.com> <535A92FD.5080009@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg01711.txt.bz2 On 04/25/2014 08:05 PM, Kai Tietz wrote: > 2014-04-25 18:53 GMT+02:00 Pedro Alves : >> On 04/19/2014 09:41 PM, Kai Tietz wrote: >> >>> Isn't this function something better placed in libiberty? Also this name looks a bit confusing. Wouldn't be a an function calling for _WIN32 case also stat, and just overrides the st_mode member, if it is a link better. So I would put this function to the file_... API of libiberty. >> >> I'd even suspect that e.g., GNU Make / Makefiles would be likewise affected >> by this. A solution for this in gcc, or in a few selected programs >> only, looks brittle to me. Perhaps it should be mingw itself that provides >> a _non-default_ replacement as option (similarly to __mingw_printf). > > Of course we could change default-behavior of stat-function within > mingw. Huh? I said exactly the opposite. To expose it as a __non-default__ replacement. I pointed at __mingw_printf, so to suggest programs would call it like __mingw_stat or something, or by defining __USE_MINGW_POSIX_STAT or something, just like one can define __USE_MINGW_ANSI_STDIO before including stdio.h. I'll understand if you wouldn't want to support that as an option, but I did _not_ suggest making it the default. > This would change documented and exprected behavior of > msvcrt's implementation. And all this for an assumption made by some > ventures. "some ventures" here must be the whole toolchain. Certainly the whole toolchain needs to agree on path handling. Makefiles were an obvious example -- if the preprocessor needs needs to find the right include files, so must Make need this to pick the right dependencies, isn't it? This sort of potencially-needing-to-be-fixed-in-many-places issue is what makes me believe a much better solution would be to just not rely on this semantics in the first place. > I think that libiberty is exactly present to unify functionality (and > API) for different operation systems. Exactly for this libiberty was > made, isn't it? libiberty is actually a kitchen sink, and specific to gcc and src. It does more than host abstraction. Gnulib fills that role much better nowdays. I'd be nice if gcc used that instead for the host abstraction parts (gdb does), but nobody's working on that afaik... > I agree that there are other venture, which might be affected by same > problem. So those venture could either use libiberty to solve this > problem too, or need to reimplement it as they do now. And then we'll have reinvented Cygwin all over the map. ;-) >> Can't glibc be changed to not rely on this? /me hides. -- Pedro Alves