bug#59427: CC Mode 5.35.2 (C/*l); More bad fontification

Alan Mackenzie <[email protected]> Fri, 25 Nov 2022 10:05:59 +0000
Newsgroups gmane.emacs.cc-mode.general
Message-ID <Y4CThzfST/SoLrgU@ACM>
Hello, Michael.

On Thu, Nov 24, 2022 at 22:20:42 -0500, Michael Welsh Duggan wrote:
> Alan Mackenzie <[email protected]> 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
> ([email protected])

-- 
Alan Mackenzie (Nuremberg, Germany).