The words 'prefix' and 'postfix' sounded too much like horizontal
concepts, like in operators. The actual purpose of these variables is to
add blank lines before and after the current line, so use the same
wording as in the command line options.
No functional change.
It's hard to follow a condition that combines many negated terms with
'||'. Group the conditions by their origin.
The condition '!opt.break_after_comma && break_comma' still sounds like
a contradition, more investigations to follow.
No functional change.
The previous name was already an improvement over the name before that
(n_real_blanklines), but didn't express the intended purpose clearly
enough, so try another name.
No functional change.
On i386 and other platforms where LONG_MAX == INT_MAX, the test
t_errors/option_tabsize_very_large failed since the behavior on integer
overflow differs between ILP32 and LP64 platforms. Noticed by gson@.
Avoid this unintended difference by adding reasonable limits for each of
the integer options and by replacing atoi with strtol.
The extra line width for comments to the very right is just that, an
arbitrarily chosen number. It neither has to be a multiple of 8, nor of
the tabsize nor of the indentation. Since 25 is neither of these, this
makes it a perfect choice, allowing these extreme comments to have 22
characters per line with -sc (leading asterisks in comment
continuations, the default) or 25 without.
No functional change.
Previously, bool options were allowed to have trailing garbage. For
example, the option '-bacc' could be spelled '-bacchus' as well.
Check that the exact option name is given in the command line, to
prevent typos in the configuration files and to reduce surprises just in
case a future option is a prefix of an existing option, or vice versa.
Add a new test program for error handling. Most of these tests are so
simple that it would be overkill to create 3 files for each test.
The comment above the code was wrong. The leading 3 characters were
indeed ignored, but the first of them was '/', not ' '. Of the trailing
3 characters, 2 were not ignored. The start and end of the comment would
not cancel out, they would rather sum up.
Since 1978, 'global' has not been a keyword in C. Moreover, it was
declared as a type while its name would rather suggest a storage class.
Removing the keyword fixes the formatting of variables named 'global'.
The input buffer is always supposed to be terminated with a newline. The
function inbuf_read_line silently skips null characters. Since the input
buffer is redirected to a temporary buffer in some cases, do not simply
remove this supposed dead code, but replace it with assertions.
In any case, if the code for calling inbuf_read_line had been reachable
and actually allocated a different buffer, continuing to use the pointer
p would have invoked undefined behavior anyway.
Just writing it to stdout is bad, especially when indent is used in
filter mode. Silently continuing after such an error is bad as well.
echo '/*' | indent
This variable is only used in a single function, and that function does
not call any other function that could replace the parser state or
install a temporary parser state.
No functional change.
Unexport typenames list.
Replace standard binary search with custom binary search that returns
the inserting position.
In is_typename, take advantage of the buffer type instead of using
the standard C recipe for str_ends_with.
No functional change.
Sort the macros, remove redundancy from comment.
Remove redundant lint comment. Lint still does not recognize
__attribute__((__noreturn__)), but it also doesn't perform advanced
control flow analysis, so there is no point in having the comment, as it
doesn't suppress any warnings.
No functional change.
The formatting looks mostly OK.
Some struct members had excessively long names, leaving no space for
their corresponding comments. Renamed some of them using well-known
abbreviations.
The formatting for debug_vis_range is messed up, no idea why. It is
clearly a function declaration, not a function definition, so there is
no need to place the function name in column 1.
No functional change.
The first attempt at formatting C99 comments was conceptually wrong. It
accessed the next token in dump_line, even though that function should
only ever look at the buffers for the label, the code and the current
comment. (Understanding that part of the code was difficult at that time
due to the sheer number of global variables.) The complicated and
ever-growing condition for whether to output the token was a hack and in
retrospect doesn't make sense at all, that's why it only came close to
the intended effect.
Some unintended side effects were that the C99 comments had an
additional space in front of them, and that in some cases an empty line
followed the comment, and that the comments were not aligned.
Previously, the newline that terminates the C99 comment was included in
the comment. Separating the newline from the comment fixed all these
unintended side effects. The only downside is that the multi-line
statement is not indented, but that should be easy to fix.
rillig