From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19813 invoked by alias); 6 Apr 2006 14:05:47 -0000 Received: (qmail 19800 invoked by uid 22791); 6 Apr 2006 14:05:46 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 06 Apr 2006 14:05:44 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FRV7G-0006pY-LH; Thu, 06 Apr 2006 10:05:42 -0400 Date: Thu, 06 Apr 2006 14:41:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: text file formats Message-ID: <20060406140542.GA26169@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com References: <20060405223122.GB11610@brasko.net> <20060405233938.GA11013@nevyn.them.org> <20060406001455.GC11610@brasko.net> <20060406011732.GA12814@nevyn.them.org> <20060406032702.GE11610@brasko.net> <20060406133829.GI11610@brasko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060406133829.GI11610@brasko.net> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes 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-04/txt/msg00062.txt.bz2 On Thu, Apr 06, 2006 at 09:38:29AM -0400, Bob Rossi wrote: > OK, this is interesting in brings up 2 cases. (They may be the same > though). Why are you going to tremendous lengths to accomodate non-native newline conventions? Is there some good reason I've missed? Your example about the slightly mangled RHEL3 header doesn't cut it. That's the least problematic form of mixing. You'll just get stray non-printables at the end of lines. You can go to all the trouble you want, but the fact is, GDB only supports files using the native convention. So no wonder you can't get it to match. If you really need anything more, I recommend just detecting the case and warning. > GDB writes every line to the current line when listing the mac file. > It is overwritten via the "\r". Notice that the 'info source' command > thinks the file is 1 line long. This isn't correct IMO. Is it to anyone > else? That is a correct interpretation of a file containing only '\r' line separators on a Unix platform. > Breakpoint 3, macf (i=1) at mac.c:4 > Line number 4 out of range; mac.c has 1 lines. That is GCC's interpretation of a file containing only '\r' separators on a Unix platform. It is also valid. -- Daniel Jacobowitz CodeSourcery