From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25096 invoked by alias); 13 Oct 2009 05:21:22 -0000 Received: (qmail 25085 invoked by uid 22791); 13 Oct 2009 05:21:20 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 05:21:15 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E1D592BAC41; Tue, 13 Oct 2009 01:21:13 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id E0FqWz4EnMlm; Tue, 13 Oct 2009 01:21:13 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 3750A2BAC40; Tue, 13 Oct 2009 01:21:13 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 03AD0F58A0; Mon, 12 Oct 2009 22:21:02 -0700 (PDT) Date: Tue, 13 Oct 2009 05:21:00 -0000 From: Joel Brobecker To: Danny Backx , gdb-patches Subject: Re: shared lib dos filename style - one more question Message-ID: <20091013052101.GI5272@adacore.com> References: <1253973110.10921.76.camel@pavilion> <1254946075.10921.178.camel@pavilion> <20091007201145.GA21557@caradoc.them.org> <1255017831.10921.197.camel@pavilion> <20091009173650.GB5272@adacore.com> <1255114781.10921.217.camel@pavilion> <20091010021849.GC5272@adacore.com> <20091012204451.GA17607@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091012204451.GA17607@caradoc.them.org> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00257.txt.bz2 > There's nothing straightforward that this latter approach could do for > case-sensitivity problems, though - is there? I'd prefer not to > completely rule out handling this case. Hmmm, I was indeed carefully side-stepping this issue, busted :). I was hoping that this wasn't going to matter in practice... > I wonder if the best solution wouldn't be a tri-state setting, > defaulting to 'auto' - DOS style on DOS/Windows hosts, also > recognizing forward slashes; Unix style on Unix hosts, also > recognizing drive letters and backslashes. > > I haven't thought entirely about the pain involved in supporting > wrong-case files. Maybe this is just wrong-headed... if open failed, > we'd have to do a wrong-case search, and that could get seriously out > of hand. So maybe this is nuts... I guess this could indeed get seriously out of hand, but I'm not so sure about that. I'm thinking we could rapidly fail within the first few elements of the path. But regardless, having a tri-state setting should help prevent that - only the users requiring case-insensitive matching on Unix hosts would be paying the potential cost. > Anyway, I'd prefer a global solution rather than one local to > solib_find. Me too. -- Joel