GNU bug report logs - #7446
Emacs 23.2 [windows] - Buffer overrun bug with ebrowse.exe

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Joe Matarazzo <joe.matarazzo <at> gmail.com>
Subject: bug#7446: closed (Re: bug#7446: Emacs 23.2 [windows] - Buffer
 overrun bug with ebrowse.exe)
Date: Sat, 27 Nov 2010 09:26:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#7446: Emacs 23.2 [windows] - Buffer overrun bug with ebrowse.exe

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 7446 <at> debbugs.gnu.org.

-- 
7446: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7446
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joe Matarazzo <joe.matarazzo <at> gmail.com>
Cc: 7446-done <at> debbugs.gnu.org
Subject: Re: bug#7446: Emacs 23.2 [windows] - Buffer overrun bug with
	ebrowse.exe
Date: Sat, 27 Nov 2010 11:32:03 +0200

> Date: Fri, 19 Nov 2010 16:39:49 -0800
> From: Joe Matarazzo <joe.matarazzo <at> gmail.com>
> Cc: 
> 
> When the input file ends with a C++ style "//" comment line, without a
> newline at the end, the parser will attempt to read past the end of
> the input buffer. This produces undefined results, among them putting
> the parser in a bogus state that makes all subsequent input files
> parse incorrectly. Here's a possible fix:

Thanks, I applied this patch to the Emacs 23 branch.

[Message part 3 (message/rfc822, inline)]

From: Joe Matarazzo <joe.matarazzo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emacs 23.2 [windows] - Buffer overrun bug with ebrowse.exe
Date: Fri, 19 Nov 2010 16:39:49 -0800

When the input file ends with a C++ style "//" comment line, without a
newline at the end, the parser will attempt to read past the end of
the input buffer. This produces undefined results, among them putting
the parser in a bogus state that makes all subsequent input files
parse incorrectly. Here's a possible fix:


--- old/ebrowse.c  2010-04-03 15:26:07 -0700
+++ new/ebrowse.c    2010-11-19 16:36:13 -0800
@@ -1784,6 +1784,10 @@
             case '/':
              while (GET (c) && c != '\n')
                ;
+
+              if (c == 0)
+                return YYEOF;
+
              INCREMENT_LINENO;
              break;

I'm not subscribed to the list. Please direct any follow up questions
directly to my email.

Thanks,
Joe

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.