GNU bug report logs - #39409
CC Mode 5.33.1 (C/*l); Wrong fontification of "foo * sizeof"

Previous Next

Package: cc-mode;

Reported by: Benjamin Moody <benjaminmoody <at> gmail.com>

Date: Mon, 3 Feb 2020 23:03:02 UTC

Severity: normal

Fixed in version 27.0.60

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

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Alan Mackenzie <acm <at> muc.de>
To: Benjamin Moody <benjaminmoody <at> gmail.com>
Cc: 39409 <at> debbugs.gnu.org
Subject: bug#39409: CC Mode 5.33.1 (C/*l); Wrong fontification of "foo * sizeof"
Date: Wed, 5 Feb 2020 20:57:27 +0000
Hello, Benjamin.

Thank you for taking the trouble to report this bug, and thanks even
more for appending a full CC-Mode configuration dump from C-c C-b.

On Mon, Feb 03, 2020 at 18:02:22 -0500, Benjamin Moody wrote:
> Emacs gives slightly odd fontification for the following C source:

> int *foo(int length)
> {
>   return malloc(length * sizeof(int));
> }

> In either C or C++ mode, the identifier 'length' in the third line is
> formatted as a type name (font-lock-type-face).  (In ObjC mode, this
> doesn't happen.)

The problem was actually fixed in 2017, but hasn't yet made it through
to a released version of Emacs.

> I'm not sure if this problem is limited to "identifier followed by '*'
> followed by 'sizeof'", but that pattern occurs often enough to be
> distinctive. :)

The problem was an awkward ambiguity, where 

    foo * bar(baz)

could be either a multiplication of foo by the result of calling bar, or
the declaration of a function bar taking a parameter of type baz and
returning a pointer to something of type foo.

One really needs semantic analysis to resolve this properly, but until
that happens, the workaround adopted is to use the (a)symmetry of
whitespace around the * operator - If we have one of

    foo * bar(baz)
    foo*bar(baz)

we treat the * as a mulplication.  If we have one of

    foo *bar(baz)
    foo* bar(baz)

the whole thing is a function declaration.  This seems to work, more or
less, in most cases.

I would recommend you to upgrade your CC Mode.  There are several ways
to do this, in order of increasing work to you:
1/- Wait until the release of Emacs 27.1.  This will be several months
away, but probably less than a year.
2/- Ask me to send you a tarball of the current CC Mode in Emacs.
3/- Download the last released standalone CC Mode 5.34 from
http://cc-mode.sourceforge.net/ (Note: the standalone version and that
in Emacs have drifted apart, somewhat).
4/- Get the head of the Mercurial repository at the above address.
5/- Check out the entire Emacs repository from https://savannah.gnu.org,
and use the not-quite-in-pretest Emacs version 27.
6/- Extract the CC Mode sources from the Emacs repository, and use those
in Emacs 26.

In all these methods apart from the first, you will need to byte compile
the CC Mode sources (which isn't difficult).

> Emacs  : GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)
>  of 2019-09-22, modified by Debian
> Package: CC Mode 5.33.1 (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 1-bit)

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).







This bug report was last modified 5 years and 161 days ago.

Previous Next


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