From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5211 invoked by alias); 13 Nov 2004 21:46:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5186 invoked from network); 13 Nov 2004 21:46:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 13 Nov 2004 21:46:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CT5im-00083k-4R; Sat, 13 Nov 2004 16:46:12 -0500 Date: Sat, 13 Nov 2004 21:59:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: otto.wyss@orpatec.ch, gdb@sources.redhat.com Subject: Re: GDB doesn't show the correct line Message-ID: <20041113214612.GA30909@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , otto.wyss@orpatec.ch, gdb@sources.redhat.com References: <40D5E480.4A68163@orpatec.ch> <20040620202929.GA17216@nevyn.them.org> <40D7212F.E68A9D61@orpatec.ch> <20040621175928.GA13407@nevyn.them.org> <40D725AF.FC2AAF3A@orpatec.ch> <20041113201803.GA21320@nevyn.them.org> <01c4c9c9$Blat.v2.2.2$913fbf20@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c4c9c9$Blat.v2.2.2$913fbf20@zahav.net.il> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-11/txt/msg00131.txt.bz2 On Sat, Nov 13, 2004 at 11:40:40PM +0200, Eli Zaretskii wrote: > > Date: Sat, 13 Nov 2004 15:18:03 -0500 > > From: Daniel Jacobowitz > > Cc: gdb@sources.redhat.com > > > > It's no one's fault, I think. I tracked down the problem. You have > > mixed newline conventions in the file: mostly "\n" as a line separator, > > but in some places just "\r". GCC treats this as a line break for > > legacy reasons (MacOS). 'less' doesn't, which really confused me while > > trying to debug the problem. GDB doesn't, either. > > > > Should GDB? I have no idea. > > As of today, GDB should treat \r\n (a.k.a. CR-LF) line endings > correctly, but not sole \r. Perhaps we should amend that code to > treat sole CRs as well. I'm not inclined to do this. If we're already in the presence of mixed line endings, who's to say we aren't mixing \r, \n, and \r\n? Hmm. Eli, how would you feel about complaining about this situation? If we read in a file and discover more than one kind of line ending, we're likely to get confused. > > But it's easiest to just fix the source file to be consistent. > > Indeed. Which is why I prefer this solution :-) -- Daniel Jacobowitz