From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22241 invoked by alias); 6 Apr 2006 03:43:45 -0000 Received: (qmail 22233 invoked by uid 22791); 6 Apr 2006 03:43:44 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Apr 2006 03:43:44 +0000 Received: from HOME-C4E4A596F7 (IGLD-83-130-213-56.inter.net.il [83.130.213.56]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DXE88514 (AUTH halo1); Thu, 6 Apr 2006 06:43:40 +0300 (IDT) Date: Thu, 06 Apr 2006 03:43:00 -0000 Message-Id: From: Eli Zaretskii To: gdb@sources.redhat.com In-reply-to: <20060405223122.GB11610@brasko.net> (message from Bob Rossi on Wed, 5 Apr 2006 18:31:22 -0400) Subject: Re: text file formats Reply-to: Eli Zaretskii References: <20060405223122.GB11610@brasko.net> 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/msg00048.txt.bz2 > Date: Wed, 5 Apr 2006 18:31:22 -0400 > From: Bob Rossi > > However, it is easy to mix these file formats. In this case, any particular > file can use any combination of "\r", "\r\n" and "\n" for newlines. I'm not > even sure how to display such a file. I'm guessing that's it's > ambiguous, and i can make a best guess as to what the newline sequence > should be. Is this correct? > > One thing I have determined, is that in order to know what the file > format is, the entire text file needs to be parsed. After that, either > the file format is defined (unix/dos/mac) or it is undefined (mix of > them). (a) For native end-of-line (EOL) format, use the native C library and specify the text-mode I/O when you open the file. (b) For non-native but consistent EOL format, read the file in binary mode, analyze its first chunk, and then manually convert the original EOL markers into literal \n. The only two methods I know of to handle the mixed case are: (1) Fall back to Unix-style EOL and show the ^M literally. (2) Let the user specify the EOL and then apply the (b) strategy above. > I would like to make sure that the algorithm CGDB uses to determine > the line number from a file is the same algorithm that GDB uses. GDB doesn't solve any of these problems. But I think that your motivation for doing the same as GDB was based on incorrect assumptions, see Daniel's and my responses elsewhere in this thread.