Re: GDB on Mac is (NOT) Broken

[YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>]

>>>>> On Sat, 20 Mar 2010 15:45:59 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

>> +   ;; Workaround for some Apple versions of GDB that add ^M at EOL
>> +   ;; after the command "server interpreter mi -stack-info-frame".
>> +   (if (string-match "(Apple version " gdb-first-output-line)
>> +       (let* ((process (get-buffer-process gud-comint-buffer))
>> + 	     (coding-systems (process-coding-system process)))
>> + 	(set-process-coding-system process
>> + 				   (coding-system-change-eol-conversion
>> + 				    (car coding-systems) 'dos)
>> + 				   (cdr coding-systems))))
>> + 

> Actually, detecting the CRLF itself would be better.  But at least this
> seems "safe for GNU".  So I think it's acceptable for 23.2.

Strangely, the EOL style suddenly changes from LF to CRLF after the
command "server interpreter mi -stack-info-frame", .  I.e., the first
output line ends with LF.  Maybe I'll improve the comment.

>> +       (if (not (string-match "\n" gdb-first-output-line))
>> + 	  (setq gdb-first-output-line
>> + 		(concat gdb-first-output-line
>> + 			(if (string-match "\n" output)
>> + 			    (substring output 0 (match-end 0))
>> + 			  output))))
>> output)))
  
> Rather than string-match, you can
> (eq ?\n (aref gdb-first-output-line (1- (length gdb-first-output-line))))

Currently, gdb-first-output-line is initialized to "".  And I thought

  (and (not (string= gdb-first-output-line "")
       (eq ?\n (aref gdb-first-output-line
                     (1- (length gdb-first-output-line))))

a bit awkward and doubted its merit because it involves more
bytecode-level operations.  Of course, one can initialize the variable
to some dummy non-empty string, but it doesn't look natural.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp