mechanical changes

Russ Allbery 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:

indent \
    -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.

Bugs:

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

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

Feature requests:

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

int
dummy(void)
{
    return (0 == 1);
}


bool
example(struct foo *bar, const char *first, ...)
{
    va_list args;
    const char *string;

    va_start(args, first);
    for (string = first; string != NULL; VA_NEXT(string, const char *))
        ;
    va_end(args);

    /* This comment has length that puts the closing comment at the line
       end. */
    (*bar->function)(string);
}


-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>


More information about the inn-workers mailing list