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).