From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22501 invoked by alias); 13 Aug 2006 20:33:33 -0000 Received: (qmail 22493 invoked by uid 22791); 13 Aug 2006 20:33:32 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 13 Aug 2006 21:33:31 +0100 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id BD16A48CDCC for ; Sun, 13 Aug 2006 16:33:28 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17814-01-10 for ; Sun, 13 Aug 2006 16:33:28 -0400 (EDT) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 5BCF448CC3E for ; Sun, 13 Aug 2006 16:33:28 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id B922647EFA; Sun, 13 Aug 2006 13:33:27 -0700 (PDT) Date: Sun, 13 Aug 2006 20:33:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Re: How to set a breakpoint in file, which name has spaces? Message-ID: <20060813203327.GI1315@adacore.com> References: <44DAD087.30004@sun.com> <20060810125827.GA18306@nevyn.them.org> <44DB6093.4030905@sun.com> <20060810175119.GA26275@nevyn.them.org> <44DC151F.3030009@sun.com> <20060811134842.GA19749@nevyn.them.org> <20060811201331.GA533@adacore.com> <20060813180239.GA3481@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060813180239.GA3481@nevyn.them.org> User-Agent: Mutt/1.4i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00114.txt.bz2 > > I will try to remember. IMO, it wouldn't be a bad idea to design > > and implement the new syntax now. We can then decide to do the major > > version number bump. > > Yes, that's reasonable - although I personally have other priorities, > so maybe for some future version bump :-) I know what you mean :-). That's why I suggested working on this first, whenever that might happen, and then do the version number bump, rather than having the version number drive when we work on it. -- Joel