rra at stanford.edu
Sun Mar 11 12:13:14 UTC 2001
Russ Allbery <rra at Stanford.EDU> writes:
> Marco d'Itri <md at Linux.IT> writes:
>> - run indent -kr on all files
> I'm not sure about this one. A couple of times, I've put a bit of effort
> into getting indent working well enough that we could just run it on
> everything, but it keeps having niggling problems.
I've gone ahead and reported the problems I ran into with indent to the
maintainer. For the curious, here's the message I sent:
To: indent at alinoe.com
Subject: [indent 2.2.6] Several small bug reports and feature requests
From: Russ Allbery <rra at stanford.edu>
Date: 11 Mar 2001 04:08:13 -0800
I'm using GNU indent 2.2.6 with the following options:
-bad -bap -nsob \
-fca -lc78 -cd32 -cp1 \
-br -ce -cdw -cli0 -ss -npcs -cs \
-di1 -nbc -psl -brs \
-i4 -ci4 -lp -ts8 -nut -ip5 -lps \
-l78 -bbo -hnl \
-T off_t -T size_t -T uint32_t -T time_t -T FILE
At the end of this message is a sample little program that illustrates all
of the bugs and desired features.
- indent still apparently gets confused about some constructs and thinks
that they're declarations. In particular, I usually define a macro
VA_NEXT that is a wrapper around va_arg (see attached program), and in
a typical invocation of that wrapper in a for loop, indent thinks that
it's a declaration and with -bad adds a blank line after the for
- Something about a return in a previous function that includes an
expression enclosed in parentheses causes the spacing of a struct
pointer in the arguments of the following function to be wrong. A
space is added turning "struct foo *bar" into "struct foo * bar". This
sounds like a very strange interaction, but the little dummy function
in the enclosed test program appears to be the nearly minimal case to
trigger this bug. The effect lasts through several functions (the next
few functions in the source file where I noticed this were also
affected) and then disappears; I can't tell what triggers the spacing
going back to normal.
- Currently, indent always turns "(*func)(arg)" into "(*func) (arg)"
(this appears to be independent of -cs or -ncs, so I don't think it's
simply that (*func) is being confused with a cast). My preferred style
is "(*func)(arg)" instead; I'd love an option that would allow that.
- I always write empty for loops as:
for (++p; *p == '*'; p++)
with the semicolon on the following line. I see that indent has an
option to put a space before it and put it on the same line, but there
doesn't appear to be a function to put it on the following line. I
took a look at how to implement this, since it sounds conceptually easy
(indent already recognizes this syntax element), but I couldn't see in
a quick look how to insert the current indentation level plus another
indent before the semicolon.
- If a comment is exactly the acceptable length without the closing "*/",
indent puts "*/" on the following line by itself. This looks very odd
to me; I'd much rather that indent treat the space between the last
word of the comment and the "*/" as "non-breaking" and therefore wrap
the last word of the comment down to the next line along with "*/".
Here is the sample program. My ideal would be an invocation of indent
that would leave this program completely unchanged.
Thank you very much for an excellent program! These reports came out of
an attempt to develop indent options so that we can run all of INN through
indent and then automatically run indent on the file with each checkin and
thereby maintain a consistent coding standard. indent seems *almost*
ready for that.
#define VA_NEXT(var, type) ((var) = (type) va_arg(args, type))
return (0 == 1);
example(struct foo *bar, const char *first, ...)
const char *string;
for (string = first; string != NULL; VA_NEXT(string, const char *))
/* This comment has length that puts the closing comment at the line
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers