Right now, when a variable expression cannot be parsed, the result of
calling Var_Subst is a string containing garbage, and no error is
reported. In addition, there are some silent errors that are not
reported at all. This combination makes it difficult to change the
error handling without introducing subtle breakage in some edge cases.
An example for garbage output is in varmod-subst-regex.mk, in target
mod-regex-compile-error.
No functional change.
The modifier ':C' now only compiles the regular expression if the result
of the expression is actually needed.
Several other modifiers have the same bug of evaluating the expression
in cases where this is not needed. It just doesn't show up because they
don't have any noticeable side effects, other than wasting CPU time.
This affects irrelevant conditions as well.
The additional parameter last_bl_ptr was only necessary because the last
blank was stored as a pointer into the buffer. By storing the index in
the buffer instead, it doesn't need to be updated all the time.
No functional change.
- Use jeq instead of jra for conditional branch.
- Use cmpl instead of cmp (= cmpw) for int variables.
Now, my Quadra 800 recognizes full 520MB memory!
avoid hashing/assigning large structure. Upper-bound is arbitrary, but
be carefully for performance penalty if bumping.
Thanks christos for discussion.
The '?:' operator computing the factor was too hard to read. When
quickly scanning the code, the 1 in the expression looked too much like
it would be added to the indentation, which would turn the indentation
length into a column number, and that again would smell like an
off-by-one error.
No functional change.
The manual page says that the default maximum length of a comment line
is 78. The test 'comments.0' wrongly assumed that this 78 would refer
to the maximum _column_ allowed, which is off by one.
Fix the wording in the test 'comments.0' and remove the (now satisfied)
expectation comments in the test 'token-comment.0'.
Several other tests just happened to hit that limit, fix these as well.
Formatting indent.h required the following manual corrections
afterwards:
The first tab in the comment in line 1 was replaced with a space but
shouldn't be.
The spacing around the '...' in function prototypes was completely
wrong. It looked like 'const char *,...)__printflike', without any
spaces.
The '*' of the return type 'const char *' was tied to the function name,
even though this declaration was only for a single function. In such a
case, it's more appropriate to line up the function names.
The function-like macros were not indented to -di. This is something
that I would not expect from indent, so it's ok to do that manually.
column == 1 + indentation.
In addition, indentation is a relative distance while column is an
absolute position. Therefore, don't confuse these two concepts, to
prevent off-by-one errors.
No functional change.
Previously, the '/*' in the string literal had been interpreted as the
beginning of a comment, which was wrong. Because of that, the variable
declaration in the following line was still interpreted as part of the
comment. The comment even continued until the end of the file.
Due to indent's forgiving nature, it neither complained nor even
mentioned that anything had gone wrong. The decision of rather
producing wrong output than failing early is a dangerous one.
At least, there should have been an error message that at the end of the
file, the parser was still in a a comment, expecting the closing '*/'.
In process_preprocessing, the variable 'quote' is not used, which makes
the code suspicious of not handling the combination of string literals
and comments properly.
Since several years (maybe even decades) compilers know how to inline
static functions that are only used once. Therefore there is no need to
have overly long functions anymore, especially not 'main', which is only
called a single time and thus does not add any noticeable performance
degradation.
No functional change.
The word 'col' should only be used for the 1-based column number. This
name is completely inappropriate for a line length since that provokes
off-by-one errors. The name 'cols' would be acceptable although
confusing since it sounds so similar to 'col'.
Therefore, rename variables that are related to the maximum line length
to 'line_length' since that makes for obvious code and nicely relates to
the description of the option in the manual page.
No functional change.
These two functions operated on column numbers instead of indentation,
which required adjustments of '+ 1' and '- 1'. Their names were
completely wrong since these functions did not count anything, instead
they computed the column.
No functional change.
rillig