bug#28418: 25.2; c++ angle bracket incorrect mismatch

bug#28418: 25.2; c++ angle bracket incorrect mismatch

[Tanis, Craig]

The opening angle bracket from the stream insertion operator (<<)
becomes misclassified as an opening delimiter if a later string literal in the
file contains >>

See the following sample file.  Notice that you must type in the string
as indicated because the act of typing triggers the misclassification.
When the error occurs, the closing bracket matches the '<' right before "nice". 

I suggest pasting this into a new file and then manipulating the first string.


//---------------------------
int main(int argc, char *argv[])
{
  std::cout << "nice"; // <-- manually type in this string
  return 0;
}

void subroutine()
{
    char* foo= "a >> b";
    return;
}

//---------------------------






In GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
of 2017-04-21 built on builder10-9.porkrind.org
Windowing system distributor 'Apple', version 10.3.1504
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-modules'

Configured features:
NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C++/l

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
up-list: Scan error: "Unbalanced parentheses", 34, 1
Saving file /Users/ctanis/Desktop/foo.cpp...
Wrote /Users/ctanis/Desktop/foo.cpp
user-error: The mark is not set now, so there is no region
Undo!

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils
cl-extra help-mode cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs pcase cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel ns-win ucs-normalize term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame
cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote kqueue cocoa ns
multi-tty make-network-process emacs)

Memory information:
((conses 16 215382 7642)
(symbols 48 21583 0)
(miscs 40 52 152)
(strings 32 20302 6885)
(string-bytes 1 698238)
(vectors 16 35302)
(vector-slots 8 678284 5012)
(floats 8 162 29)
(intervals 56 258 9)
(buffers 976 18))


----
Craig Tanis, PhD
UTC Computer Science and Engineering
craig-tanis@utc.edu

bug#28418: 25.2; c++ angle bracket incorrect mismatch

[Alan Mackenzie]

Hello, Craig.

In article <mailman.329.1505143569.14750.bug-gnu-emacs@gnu.org> you wrote:



> The opening angle bracket from the stream insertion operator (<<)
> becomes misclassified as an opening delimiter if a later string literal in the
> file contains >>

Firstly, thanks for taking the trouble to report this bug, and thanks
even more for trimming it down to a nice, easy to work with snippet.

> See the following sample file.  Notice that you must type in the string
> as indicated because the act of typing triggers the misclassification.
> When the error occurs, the closing bracket matches the '<' right before "nice". 

Being more precise, I think the >> in the string already has to exist at
the time the << gets typed.

> I suggest pasting this into a new file and then manipulating the first string.


> //---------------------------
> int main(int argc, char *argv[])
> {
>   std::cout << "nice"; // <-- manually type in this string
>   return 0;
> }

> void subroutine()
> {
>     char* foo= "a >> b";
>     return;
> }

> //---------------------------

What seems to be happening is after typing in the opening " of "nice",
but before typing in the closing ", we have a sort of string extending
from that opening " to the opening " of "a >> b".  That >> is
(temporarily) outside a string, and is thus balanced with the <<.  This
balancing is done by applying a "text property" to each of the second <
and the first > characters.

Where things go wrong is when "nice" is closed by typing the closing ".
At this point, the text properties don't get removed from these < and >,
although they no longer match.  This is the fault in the code.

Give me a little time, and I will fix it.




> In GNU Emacs 25.2.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1911))
> of 2017-04-21 built on builder10-9.porkrind.org
> Windowing system distributor 'Apple', version 10.3.1504
> Configured using:
> 'configure --with-ns '--enable-locallisppath=/Library/Application
> Support/Emacs/${version}/site-lisp:/Library/Application
> Support/Emacs/site-lisp' --with-modules'

> Major mode: C++/l

[ .... ]

> ----
> Craig Tanis, PhD
> UTC Computer Science and Engineering
> craig-tanis@utc.edu

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#28418: 25.2; c++ angle bracket incorrect mismatch

[Alan Mackenzie]

Hello again, Craig.

On Mon, Sep 11, 2017 at 17:55:08 -0000, Alan Mackenzie wrote:
> In article <mailman.329.1505143569.14750.bug-gnu-emacs@gnu.org> you wrote:



> > The opening angle bracket from the stream insertion operator (<<)
> > becomes misclassified as an opening delimiter if a later string literal in the
> > file contains >>

> Firstly, thanks for taking the trouble to report this bug, and thanks
> even more for trimming it down to a nice, easy to work with snippet.

> > See the following sample file.  Notice that you must type in the string
> > as indicated because the act of typing triggers the misclassification.
> > When the error occurs, the closing bracket matches the '<' right before "nice". 

> Being more precise, I think the >> in the string already has to exist at
> the time the << gets typed.

> > I suggest pasting this into a new file and then manipulating the first string.


> > //---------------------------
> > int main(int argc, char *argv[])
> > {
> >   std::cout << "nice"; // <-- manually type in this string
> >   return 0;
> > }

> > void subroutine()
> > {
> >     char* foo= "a >> b";
> >     return;
> > }

> > //---------------------------

> What seems to be happening is after typing in the opening " of "nice",
> but before typing in the closing ", we have a sort of string extending
> from that opening " to the opening " of "a >> b".  That >> is
> (temporarily) outside a string, and is thus balanced with the <<.  This
> balancing is done by applying a "text property" to each of the second <
> and the first > characters.

> Where things go wrong is when "nice" is closed by typing the closing ".
> At this point, the text properties don't get removed from these < and >,
> although they no longer match.  This is the fault in the code.

> Give me a little time, and I will fix it.

More precisely, the error was allowing those two characters to be
matched in the first place.  This happened when trying to parse a < .. >
construct starting at the <<, which fails, since the << is not a
template delimiter.  The bug was then to move a single character
forward, then search for the next < (which is finds without moving).
Now it manages spuriously to parse the < .. >, and matches the < and the
>.  The solution is instead to move a whole token forward.

The following patch should fix this.  Please apply this to your Emacs
(cc-engine.el is in directory ..../emacs/lisp/progmodes) and recompile
cc-engine.el.  Please then check that the bug is fixed properly in your
real code, and let me know how it goes.

(If you want any help in applying the patch, or byte-compiling
cc-engine.el, feel free to contact me by private email.)

Here's the patch:


diff -r d0ed864dd852 cc-engine.el
--- a/cc-engine.el	Sun Sep 03 10:33:57 2017 +0000
+++ b/cc-engine.el	Mon Sep 11 21:02:25 2017 +0000
@@ -6431,7 +6431,7 @@
 			      (not (eq (c-get-char-property (point) 'c-type)
 				       'c-decl-arg-start)))))))
       (or (c-forward-<>-arglist nil)
-	  (forward-char)))))
+	  (c-forward-token-2)))))
 
 \f
 ;; Functions to handle C++ raw strings.



> > ----
> > Craig Tanis, PhD
> > UTC Computer Science and Engineering
> > craig-tanis@utc.edu

-- 
Alan Mackenzie (Nuremberg, Germany).




> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot

bug#28418: 25.2; c++ angle bracket incorrect mismatch

[Alan Mackenzie]

Hello, Craig.

On Mon, Sep 11, 2017 at 22:11:09 +0000, Tanis, Craig wrote:
> Alan,
> This appears to have fixed the bug, but I had to manually replace that
> line in the function, as the patch was malformed (according to patch
> version 2 .5.8 on macos sierra)

I've pushed the patch to savannah, and I'm closing the bug with this
post.

I'm not sure what happened to the patch, but I suspect that something
between my PC and yours mangled the formfeed that was on the second last
line of the three context lines following the change.  But I'm only
speculating here.  The FF appears to be missing from the version of the
patch quoted by you in the post I'm answering.

Again, thanks for the bug report!

> thanks!
> Craig

-- 
Alan Mackenzie (Nuremberg, Germany).