Article View: gnu.utils.bug
Article #722following up on indent 1.6 (forced newline in typedef)
From: Charlie Xiaoli Huang
Date: Thu, 03 Sep 1992 18:23
Date: Thu, 03 Sep 1992 18:23
63 lines
2064 bytes
2064 bytes
Following up on my previous message on a forced newline
at end of typedef, I'm convinced it is a bug. The reason
is inconsistent behavior as follows:
original:
typedef struct foo {
int bar;
} foo_t;
will become
typedef struct foo {
int bar;
}
foo_t;
whereas
original
typedef struct foo {
int bar;
struct fubar x;
} foo_t;
will become
typedef struct foo {
iunt bar;
struct fubar x;
} foo_t;
As you can see, the inserted newline before type name "foo_t"
is insterted if the last member of the struct is NOT a struct.
I've attempted to track down where in indent.c the decision
was made to set the force_nl var in this case, and made the
fix as follows:
*** indent.c Thu Sep 3 11:02:27 1992
--- indent.c.orig Wed Aug 19 15:32:29 1992
***************
*** 997,1006 ****
prefix_blankline_requested = 0;
parse (rbrace); /* let parser know about this */
if ((parser_state_tos->last_rw != rw_struct_like
- && parser_state_tos->last_rw != rw_decl /* hxl@epic.com added
- so that things like
- typedef struct won't have
- a forced newline */
&& (parser_state_tos->p_stack[parser_state_tos->tos] == stmtl
|| (parser_state_tos->p_stack[parser_state_tos->tos]
== ifhead)))
--- 997,1002 ----
It seems to work all right FOR MY CODE.
Please let me know what you think.
Thanks,
hxl
Technical Details
Message-ID:
<9209031823.AA12062@chopin.epic>Path:
arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!chopin.UUCP!hxlShow Full Headers
Complete Article Headers
Newsgroups: gnu.utils.bug Path: arc1-ca.pugleaf.net!sparky!uunet!cis.ohio-state.edu!chopin.UUCP!hxl From: hxl@chopin.UUCP (Charlie Xiaoli Huang) Subject: following up on indent 1.6 (forced newline in typedef) Message-ID: <9209031823.AA12062@chopin.epic> Sender: gnulists@ai.mit.edu Organization: GNUs Not Usenet Distribution: gnu Date: Thu, 3 Sep 1992 18:23:02 GMT Approved: bug-gnu-utils@prep.ai.mit.edu Lines: 64