GNU bug report logs - #59427
CC Mode 5.35.2 (C/*l); More bad fontification

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59427 in the body.
You can then email your comments to 59427 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: bug-gnu-emacs <at> gnu.org
Subject: CC Mode 5.35.2 (C/*l); More bad fontification
Date: Mon, 21 Nov 2022 10:32:26 +0800

Package: cc-mode

Insert the following text in a c-mode buffer:

static uint64_t
ConfineTime (uint64_t time)
{
  uint32_t milliseconds;

  /* Given a microsecond time, confine the millisecond part to
     CARD32.  */
  milliseconds = time / 1000;

  return (milliseconds * (uint64_t) 1000
	  + time % 1000);
}

Notice how "milliseconds" is recognized as a type, and the uint64_t in
the cast as an identifier.

Emacs  : GNU Emacs 29.0.50 (build 236, x86_64-pc-linux-gnu)
 of 2022-11-21
Package: CC Mode 5.35.2 (C/*l)
Buffer Style: gnu
c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)

current state:
==============
(setq
 c-basic-offset 2
 c-comment-only-line-offset '(0 . 0)
 c-indent-comment-alist '((anchored-comment column . 0) (end-block space . 1)
			  (cpp-end-block space . 2))
 c-indent-comments-syntactically-p nil
 c-block-comment-prefix ""
 c-comment-prefix-regexp '((pike-mode . "//+!?\\|\\**") (awk-mode . "#+")
			   (other . "//+\\|\\**"))
 c-doc-comment-style '((java-mode . javadoc) (pike-mode . autodoc)
		       (c-mode . gtkdoc) (c++-mode . gtkdoc))
 c-cleanup-list '(scope-operator)
 c-hanging-braces-alist '((substatement-open before after)
			  (arglist-cont-nonempty))
 c-hanging-colons-alist nil
 c-hanging-semi&comma-criteria '(c-semi&comma-inside-parenlist)
 c-backslash-column 48
 c-backslash-max-column 72
 c-special-indent-hook '(t c-gnu-impose-minimum)
 c-label-minimum-indentation 1
 c-offsets-alist '((inexpr-class . +)
		   (inexpr-statement . +)
		   (lambda-intro-cont . +)
		   (inlambda . 0)
		   (template-args-cont c-lineup-template-args +)
		   (incomposition . +)
		   (inmodule . +)
		   (innamespace . +)
		   (inextern-lang . +)
		   (composition-close . 0)
		   (module-close . 0)
		   (namespace-close . 0)
		   (extern-lang-close . 0)
		   (composition-open . 0)
		   (module-open . 0)
		   (namespace-open . 0)
		   (extern-lang-open . 0)
		   (objc-method-call-cont
		    c-lineup-ObjC-method-call-colons
		    c-lineup-ObjC-method-call
		    +
		    )
		   (objc-method-args-cont . c-lineup-ObjC-method-args)
		   (objc-method-intro . [0])
		   (friend . 0)
		   (cpp-define-intro c-lineup-cpp-define +)
		   (cpp-macro-cont . +)
		   (cpp-macro . [0])
		   (inclass . +)
		   (stream-op . c-lineup-streamop)
		   (arglist-cont-nonempty
		    c-lineup-gcc-asm-reg
		    c-lineup-arglist
		    )
		   (arglist-cont c-lineup-gcc-asm-reg 0)
		   (comment-intro
		    c-lineup-knr-region-comment
		    c-lineup-comment
		    )
		   (catch-clause . 0)
		   (else-clause . 0)
		   (do-while-closure . 0)
		   (access-label . -)
		   (case-label . 0)
		   (substatement . +)
		   (statement-case-intro . +)
		   (statement . 0)
		   (brace-entry-open . 0)
		   (brace-list-entry . 0)
		   (brace-list-close . 0)
		   (block-close . 0)
		   (block-open . 0)
		   (inher-cont . c-lineup-multi-inher)
		   (inher-intro . +)
		   (member-init-cont . c-lineup-multi-inher)
		   (member-init-intro . +)
		   (annotation-var-cont . +)
		   (annotation-top-cont . 0)
		   (topmost-intro . 0)
		   (knr-argdecl . 0)
		   (func-decl-cont . +)
		   (inline-close . 0)
		   (class-close . 0)
		   (class-open . 0)
		   (defun-block-intro . +)
		   (defun-close . 0)
		   (defun-open . 0)
		   (c . c-lineup-C-comments)
		   (string . c-lineup-dont-change)
		   (topmost-intro-cont
		    first
		    c-lineup-topmost-intro-cont
		    c-lineup-gnu-DEFUN-intro-cont
		    )
		   (brace-list-intro
		    first
		    c-lineup-2nd-brace-entry-in-arglist
		    c-lineup-class-decl-init-+
		    +
		    )
		   (brace-list-open . +)
		   (inline-open . 0)
		   (arglist-close . c-lineup-arglist)
		   (arglist-intro . c-lineup-arglist-intro-after-paren)
		   (statement-cont . +)
		   (statement-case-open . +)
		   (label . 0)
		   (substatement-label . 0)
		   (substatement-open . +)
		   (knr-argdecl-intro . 5)
		   (statement-block-intro . +)
		   )
 c-buffer-is-cc-mode 'c-mode
 c-tab-always-indent t
 c-syntactic-indentation t
 c-syntactic-indentation-in-macros t
 c-ignore-auto-fill '(string cpp code)
 c-auto-align-backslashes t
 c-backspace-function 'backward-delete-char-untabify
 c-delete-function 'delete-char
 c-electric-pound-behavior nil
 c-default-style '((java-mode . "java") (awk-mode . "awk") (other . "gnu"))
 c-enable-xemacs-performance-kludge-p nil
 c-old-style-variable-behavior nil
 defun-prompt-regexp nil
 tab-width 8
 comment-column 32
 parse-sexp-ignore-comments t
 parse-sexp-lookup-properties t
 auto-fill-function nil
 comment-multi-line t
 comment-start-skip "\\(?://+\\|/\\*+\\)\\s *"
 fill-prefix nil
 fill-column 70
 paragraph-start "[ 	]*\\(//+\\|\\**\\)[ 	]*$\\|^\f"
 adaptive-fill-mode t
 adaptive-fill-regexp "[ 	]*\\(//+\\|\\**\\)[ 	]*\\([ 	]*\\([-–!|#%;>*·•‣⁃◦]+[ 	]*\\)*\\)"
 )

Message #8 received at 59427 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 59427 <at> debbugs.gnu.org
Subject: Re: bug#59427: CC Mode 5.35.2 (C/*l); More bad fontification
Date: Thu, 24 Nov 2022 12:56:40 +0000

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

Hello, Po.

On Mon, Nov 21, 2022 at 10:32:26 +0800, Po Lu via CC-Mode-help wrote:
> Package: cc-mode

> Insert the following text in a c-mode buffer:

> static uint64_t
> ConfineTime (uint64_t time)
> {
>   uint32_t milliseconds;

>   /* Given a microsecond time, confine the millisecond part to
>      CARD32.  */
>   milliseconds = time / 1000;

>   return (milliseconds * (uint64_t) 1000
> 	  + time % 1000);
> }

> Notice how "milliseconds" is recognized as a type, and the uint64_t in
> the cast as an identifier.

Yes.  Here the "symmetric space" criterion for * was buggy.  That
criterion says if there is whitespace on neither side of the *, or both,
it is a multiplication sign.  Otherwise it is the indirection operator.

The bug was not taking the ( properly into account.  Please apply the
attached patch, which should fix this, and confirm it works OK.  Thanks!

> Emacs  : GNU Emacs 29.0.50 (build 236, x86_64-pc-linux-gnu)
>  of 2022-11-21
> Package: CC Mode 5.35.2 (C/*l)
> Buffer Style: gnu
> c-emacs-features: (pps-extended-state col-0-paren posix-char-classes gen-string-delim gen-comment-delim syntax-properties category-properties 1-bit)

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

[diff.20221123.diff (text/plain, attachment)]

Message #11 received at 59427 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: 59427 <at> debbugs.gnu.org
Subject: Re: bug#59427: CC Mode 5.35.2 (C/*l); More bad fontification
Date: Fri, 25 Nov 2022 08:37:48 +0800

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Po.
>
> On Mon, Nov 21, 2022 at 10:32:26 +0800, Po Lu via CC-Mode-help wrote:
>> Package: cc-mode
>
>> Insert the following text in a c-mode buffer:
>
>> static uint64_t
>> ConfineTime (uint64_t time)
>> {
>>   uint32_t milliseconds;
>
>>   /* Given a microsecond time, confine the millisecond part to
>>      CARD32.  */
>>   milliseconds = time / 1000;
>
>>   return (milliseconds * (uint64_t) 1000
>> 	  + time % 1000);
>> }
>
>> Notice how "milliseconds" is recognized as a type, and the uint64_t in
>> the cast as an identifier.
>
> Yes.  Here the "symmetric space" criterion for * was buggy.  That
> criterion says if there is whitespace on neither side of the *, or both,
> it is a multiplication sign.  Otherwise it is the indirection operator.
>
> The bug was not taking the ( properly into account.  Please apply the
> attached patch, which should fix this, and confirm it works OK.  Thanks!

It does, thanks.

Message #14 received at 59427 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Po Lu <luangruo <at> yahoo.com>, 59427 <at> debbugs.gnu.org
Subject: Re: bug#59427: CC Mode 5.35.2 (C/*l); More bad fontification
Date: Thu, 24 Nov 2022 22:20:42 -0500

Alan Mackenzie <acm <at> muc.de> writes:

> Hello, Po.
>
> On Mon, Nov 21, 2022 at 10:32:26 +0800, Po Lu via CC-Mode-help wrote:
>> Package: cc-mode
>
>> Insert the following text in a c-mode buffer:
>
>> static uint64_t
>> ConfineTime (uint64_t time)
>> {
>>   uint32_t milliseconds;
>
>>   /* Given a microsecond time, confine the millisecond part to
>>      CARD32.  */
>>   milliseconds = time / 1000;
>
>>   return (milliseconds * (uint64_t) 1000
>> 	  + time % 1000);
>> }
>
>> Notice how "milliseconds" is recognized as a type, and the uint64_t in
>> the cast as an identifier.
>
> Yes.  Here the "symmetric space" criterion for * was buggy.  That
> criterion says if there is whitespace on neither side of the *, or both,
> it is a multiplication sign.  Otherwise it is the indirection operator.
>
> The bug was not taking the ( properly into account.  Please apply the
> attached patch, which should fix this, and confirm it works OK.  Thanks!

Oh dear.  My personal programming style uses a "type * name" spacing for
pointers.  (More specifically, I put spaces on either side of "*", "&"
or "&&" when used to form types.)  Is this going to cause me problems in
the future?

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

Message #19 received at 59427-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 59427-done <at> debbugs.gnu.org
Subject: Re: bug#59427: CC Mode 5.35.2 (C/*l); More bad fontification
Date: Fri, 25 Nov 2022 09:53:55 +0000

Hello, Po.

On Fri, Nov 25, 2022 at 08:37:48 +0800, Po Lu wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > On Mon, Nov 21, 2022 at 10:32:26 +0800, Po Lu via CC-Mode-help wrote:
> >> Package: cc-mode

> >> Insert the following text in a c-mode buffer:

> >> static uint64_t
> >> ConfineTime (uint64_t time)
> >> {
> >>   uint32_t milliseconds;

> >>   /* Given a microsecond time, confine the millisecond part to
> >>      CARD32.  */
> >>   milliseconds = time / 1000;

> >>   return (milliseconds * (uint64_t) 1000
> >> 	  + time % 1000);
> >> }

> >> Notice how "milliseconds" is recognized as a type, and the uint64_t in
> >> the cast as an identifier.

> > Yes.  Here the "symmetric space" criterion for * was buggy.  That
> > criterion says if there is whitespace on neither side of the *, or both,
> > it is a multiplication sign.  Otherwise it is the indirection operator.

> > The bug was not taking the ( properly into account.  Please apply the
> > attached patch, which should fix this, and confirm it works OK.  Thanks!

> It does, thanks.

Thanks!  I've committed the patch, and I'm closing the bug with this
post.

-- 
Alan Mackenzie (Nuremberg, Germany).

Message #22 received at 59427 <at> debbugs.gnu.org (full text, mbox):

From: Alan Mackenzie <acm <at> muc.de>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: Po Lu <luangruo <at> yahoo.com>, 59427 <at> debbugs.gnu.org
Subject: Re: bug#59427: CC Mode 5.35.2 (C/*l); More bad fontification
Date: Fri, 25 Nov 2022 10:05:59 +0000

Hello, Michael.

On Thu, Nov 24, 2022 at 22:20:42 -0500, Michael Welsh Duggan wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > Hello, Po.

> > On Mon, Nov 21, 2022 at 10:32:26 +0800, Po Lu via CC-Mode-help wrote:
> >> Package: cc-mode

> >> Insert the following text in a c-mode buffer:

> >> static uint64_t
> >> ConfineTime (uint64_t time)
> >> {
> >>   uint32_t milliseconds;

> >>   /* Given a microsecond time, confine the millisecond part to
> >>      CARD32.  */
> >>   milliseconds = time / 1000;

> >>   return (milliseconds * (uint64_t) 1000
> >> 	  + time % 1000);
> >> }

> >> Notice how "milliseconds" is recognized as a type, and the uint64_t in
> >> the cast as an identifier.

> > Yes.  Here the "symmetric space" criterion for * was buggy.  That
> > criterion says if there is whitespace on neither side of the *, or both,
> > it is a multiplication sign.  Otherwise it is the indirection operator.

> > The bug was not taking the ( properly into account.  Please apply the
> > attached patch, which should fix this, and confirm it works OK.  Thanks!

> Oh dear.  My personal programming style uses a "type * name" spacing for
> pointers.  (More specifically, I put spaces on either side of "*", "&"
> or "&&" when used to form types.)  Is this going to cause me problems in
> the future?

Not if it hasn't done already.  The mechanism has been in place since
2017-03, a slight bug in it has just been corrected.  This criterion for
distinguishing a multiplication operator from an indirection operator is
only used as a last ditch, when everything else has failed to decide.  C
and C++ are not comfortable languages to parse with anything less than a
full compiler.

> -- 
> Michael Welsh Duggan
> (md5i <at> md5i.com)

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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