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

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

[Rolf Ade]

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.

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

[Noam Postavsky]

On Wed, Jun 15, 2016 at 9:05 PM, Rolf Ade <rolf@pointsman.de> wrote:
> However well advised such code is, gcc foo.c just compilies.

s/well/ill/? gcc compiles the below as well, but IMO you can't expect
Emacs to be able to properly handle every horrible trick that's
possible with the preprocessor.

#define BEGIN {
#define STOP ;

int main() BEGIN
  int a, b STOP
  if (a == 0) BEGIN
        if (b==0) {
          return 0 STOP
            }
}
}

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

[Alan Mackenzie]

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

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

[Rolf Ade]

Hello Alan,

Am 06/16/2016 11:18 AM, Alan Mackenzie wrote:
> [...]
> 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.

Just for the record: I stumbled about that in the wild. This function:
http://core.tcl.tk/tdom/artifact/3a53ac985a15644d?ln=2142-2535
triggers the bug.

I stripped down to a minimal example from that, not from the idea to
do "preprocessor tricks" to fool c-mode.