GNU bug report logs - #64133
CC Mode 5.35.2 (C/*l); incorrect indentation for an arrays of structs.

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jeff Norden <norden.jeff <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: CC Mode 5.35.2 (C/*l); incorrect indentation for an arrays of structs.
Date: Sat, 17 Jun 2023 10:03:24 -0500

I've verified the following behavior with c-version 5.35.2 (emacs-29,
and emacs-30 from git) and with 5.35.1 (emacs 28.2).

Place the following text into a file with a ".c" extension, and load
it with "emacs -Q".
==========================================
#include <stdio.h>
struct three_ints {
  int a, b, c;
};
int main () {
  struct three_ints numbers[]= {
    {0,1,2},
{3,4,5},
    {6,7,8}
  };
  for (int i=0; i<numbers[2].a; i++) {
    printf("ack ");
  }
  printf("\n");
}
==========================================
Move the cursor to the beginning of the line with {3,4,5} and press
<tab> to indent the line.  It will be incorrectly indented 2 spaces
more than the previous line.  Move to the next line, press <tab>,
and you'll see:

  struct three_ints numbers[]= {
    {0,1,2},
      {3,4,5},
        {6,7,8}
  };

Just using <tab> to re-indent the lines will not change anything.
But, if you add or delete white-space before {0,1,2} or {3,4,5} and
press <tab>, it *may* fix things.  It seems to depend on just what you
delete and where the cursor is.  The pattern isn't clear to me.
Once fixed, you get:

  struct three_ints numbers[]= {
    {0,1,2},
    {3,4,5},
    {6,7,8}
  };

At this point it is stable, and <tab> will work correctly.  If you
restart c-mode with "M-x c-mode", the problem re-occurs.

This bug only seems to occur when a loop or similar construct occurs
after the array declaration/initialization.  It doesn't need to
immediately follow, though.

When incorrectly indenting, "C-c C-s" shows 'defun-block-intro' syntax
for the {0,1,2} line, and 'substatement-open' for {3,4,5} and {4,5,6}.
Once it gets fixed, this changes to 'brace-list-intro' and
'brace-entry-open'.

==========================================
For a more "real world" example, start with the example program at the
end of the getopt_long(3) man page:

  https://linux.die.net/man/3/getopt_long

and move the declaration of long_options[] from inside the while loop
to before it.  (This makes long_options a global variable, instead of
local to the loop).

==========================================
I'm afraid I can't offer a patch or suggestion for a fix.  My own
attempts at "parsing" the lisp in cc-engine.el come to an abrupt halt
when my brain receives an urgent "Warning! Meltdown imminent!"
message from my subconscious -- just kidding :-).

However, I did stumble upon the following in the comments for the
`c-inside-bracelist-p' function:

 ;; CONTAINING-SEXP is the buffer pos of the innermost containing
 ;; paren.  NO IT ISN'T!!!  [This function is badly designed, and
 ;; probably needs reformulating without its first argument, ...

Thanks,
-Jeff
----------------------------
  If believing that "function is more important than form" and that "people
  are more important than technology" makes me a Luddite, then so be it!

Previous Next

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