This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: text file formats

> 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

> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]