bug#23775: 25.0.95.2; c-mode: Incorrect indentation and function bundery detection

[Alan Mackenzie <acm@muc.de>]

Hello, Rolf.
In article <mailman.1576.1466039228.1216.bug-gnu-emacs@gnu.org> you wrote:

> emacs -Q

> Open some empty buffer foo.c and put it into c-mode if already is
> (M-x c-mdoe). Insert this C code into it:

> #define foo
> int main (void) {
>   int a=0;
>   int b=0;
> #ifdef foo
>   if (a==0) {
> #else
>     if (b==0) {
> #endif
>       return 0;
>     }
>   }

> I've inserted it here as emacs -Q indents it, this is the indentation
> part of the report.

> Place the point at the beginning of function foo, then call
> c-end-of-defun, C-M-e by default in emacs -Q. Bell rings, point is
> before the last charater of the first line of main, here:

> int main (void) _P_{

> (which is clearly not the end of the function) and prompts me in the
> mini-buffer: "forward-sexp: Scan error: "Unbalanced parentheses", 29,
> 133"

> However well advised such code is, gcc foo.c just compilies.

Yes, this has come up before.  Unbalanced braces in preprocessor
statements[*] are horrendously difficult to parse - what should be done, for
example, when two arms of a #if construct have different numbers of
braces?

[*] ...by which I mean the part inside a particular arm of a preprocessor
conditional has unbalanced braces.

I tried once before to solve this problem, but didn't get very far.  What
was obvious, at the time, was that a solution would slow CC Mode down,
possibly quite a bit.

So, we've collectively decided that this bug, although real, won't be
fixed.  The best advice we can give is to arrange the C code such that
unbalanced braces in #if arms don't happen.

Sorry.

-- 
Alan Mackenzie (Nuremberg, Germany).