It's clearer now when a variable represents a toggable command line option.
Many options were stored in the parser's state structure, so fix also that.
Rewrite the macros so that they take a parameter. Consumers use it to signal
how much room in the buffer they need; this lets them do that once when
required space is known instead of doing the check once every loop step.
Also take the parameter value into consideration when resizing the buffer;
the requested space may be larger than the constant 400 bytes that the
previous version used - now it's the sum of those two values.
On the consumer side, don't copy strings byte by byte - use memcpy().
Deduplicate code that copied base 2, base 8 and base 16 literals.
Don't advance the e_token pointer once the token has been copied into
s_token. This allows easy calculation of the token's length.
The troff output in indent was invented at Sun and the online documentation
for some post-SunOS operating system includes this:
The usual way to get a troffed listing is with the command
indent -troff program.c | troff -mindent
The indent manual page in FreeBSD 1.0 already lacks that information and
troff -mindent complains about not being able to find the macro file.
It seems that the file did exist on SunOS and was supposed to be imported
into 4.3BSD together with the feature, but that has never happened.
Removal of troff output support simplifies a lot of indent's code.
vgrind(1) seems to be a promising replacement.
The trick is to copy everything from the start of the line into the buffer
that stores newlines and comments until indent finds a brace or an else.
pr_comment() will use that information to calculate the original indentation
of the boxed comment.
This requires storing two pieces of information: the real start of the
buffer (sc_buf) and the start of the comment (save_com).
The Software Package Data Exchange (SPDX) group provides a specification
to make it easier for automated tools to detect and summarize well known
opensource licenses. We are gradually adopting the specification, noting
that the tags are considered only advisory and do not, in any way,
superceed or replace the license texts.
Special thanks to Wind River for providing access to "The Duke of
Highlander" tool: an older (2014) run over FreeBSD tree was useful as a
starting point.
Initially, only tag files that use BSD 4-Clause "Original" license.
RelNotes: yes
Differential Revision: https://reviews.freebsd.org/D13133
pr_comment() did avoid adding surplus space character when a comment
contained it at the end. Now it's also paying attention to tabs.
Taken from: Piotr Stefaniak
Work-around a somewhat complex interaction within the code. From
Piotr's commit [1]:
When pr_comment() calls dump_line() for the first line of a multiline
comment, it doesn't include any indentation - it starts with the "/*".
This is consistent for both boxed and not boxed comments. Where the logic
diverges is in how it treats the rest of the lines of the comment. For box
comments indent assumes that it must not change anything, so lines are
dumped as they were, including the indentation where it exists. For the
rest of comments, it will first remove the indentation to store plain text
of the comment and then add it again where indent thinks it's appropriate
-- this is part of comment re-indenting process.
For continuations of multi-line comments, the code that handles comments
in dump_line() will use pad_output() to create indentation from the
beginning of the line (what indent calls the first column) and then write
string pointed by s_com afterwards. But if it's a box comment, the string
will include original indentation, unless it's the first line of the
comment. This is why tab characters from s_com have to be considered when
calculating how much padding is needed and the "while (*com_st == '\t')
com_st++, target += 8;" does that.
In dump_line(), /target/ is initially set to ps.com_col, so it always
assumes that indentation needs to be produced in this function, regardless
of which line of a box comment it is. But for the first line of a box
comment it is not true, so pr_comment() signals it by setting
ps.n_comment_delta, the negative comment delta, to a negative number which
is then added to /target/ in dump_line() on all lines except the first
one, so that the function produces adequate indentation in this special
case.
The bug was in how that negative offset was calculated: pr_comment() used
count_spaces() on in_buffer, which pr_comment() expected to contain
non-null terminated sequence of characters, originating from whatever
originally was on the left side of the comment. Understanding that
count_spaces() requires a string, pr_comment() temporarily set buf_ptr[-2]
to 0 in hope that it would nul-terminate the right thing in in_buffer and
calling count_spaces() would be safe and do the expected thing. This was
false whenever buf_ptr would point into save_com, an entirely different
char array than in_buffer.
The short-term fix is to recognize whether buf_ptr points into in_buffer
or save_com.
Reference:
[1]
ea486a2aa3
Taken from: Piotr Stefaniak
Multi-line comments are always block comments in KNF. Restore properly,
handling the case when a long one-liner gets wrapped and becomes a
multi-line comment.
Obtained from: Piotr Stefaniak
It's pr_comment.c that should decide whether to put a "star comment
continuation" or not. This duplicates code a bit, but it simplifies
pr_comment() at the same time since pr_comment() no longer has to "signal"
whether a star continuation is needed or not.
This change requires indent(1) to not wrap comment lines that lack a blank
character, but I think it's for the better if you look at cases when that
happens (mostly long URIs and file system paths, which arguably shouldn't
be wrapped).
It also fixes two bugs:
1. Cases where asterisk is a part of the comment's content (like in "*we*
are the champions") and happens to appear at the beginning of the line,
misleading dump_line() into thinking that this is part of the star comment
continuation, leading to misalignment.
2. Cases where blank starred lines had three too many characters on the
line when wrapped.
Reference:
3b41ee78aa
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
After a blank line was printed (to separate paragraphs in comments), the
next line was sometimes wrapped to the column at which the previous
non-empty line ended. The fix is to reset the last blank pointer (last_bl)
on newline.
References:
345663c07a
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
Modify count_spaces() to take a third parameter "end" that will make the
function return when the end is reached. This lets the caller pass a
pointer to non nul-terminated sequence of characters. Rename
count_spaces() to count_spaces_until() and reinstate count_spaces(), this
time based on count_spaces_until().
Use count_spaces_until() to recalculate current column when going through
a comment just before the fragment which decides if current line of the
comment should be wrapped. This move simplifies this code by eliminating
the need for keeping the column counter up to date every time e_com is
advanced and also reduces spread of code that has to know how many columns
a tab will produce.
Deduplicate code that decided if a comment needs a blank line at the top.
References:
d9fa3b481527185b4b33
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
The original indent(1) described unix-style comments as similar to box
comments, except the first non-blank character on each line is lined up
with the '*' of the "/*" which appears on a line by itself.
The code has been turned off for ages and -sc/-nsc make it even
less relevant.
Reference:
89c5fe2c56
Differential Revision: https://reviews.freebsd.org/D6966 (Partial)
Submitted by: Piotr Stefaniak
- ANSIfy function declarations
- braces around initializers structs within structs
- add parens in complicated expressions
- disambiguate dangling elses
- no more implicit int
- make functions static where possible
- use prototypes
- don't use varargs hack for diag()
Requested by: joerg
MFC after: 2 weeks
