This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: text file formats
- From: Eli Zaretskii <eliz at gnu dot org>
- To: gdb at sources dot redhat dot com
- Date: Thu, 06 Apr 2006 06:43:48 +0300
- Subject: Re: text file formats
- References: <20060405223122.GB11610@brasko.net>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Wed, 5 Apr 2006 18:31:22 -0400
> From: Bob Rossi <bob_rossi@cox.net>
>
> 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.