| Age | Commit message (Collapse) | Author |
|
No functional change.
|
|
These patterns shouldn't occur in practice, as their results are tricky
to predict. Generate a warning for now, and maybe an error later.
Reviewed by sjg@.
|
|
No functional change.
|
|
Sometimes we mark a variable readOnly to guard against .undef
|
|
No functional change.
|
|
Reviewed by: rillig
|
|
|
|
Sometimes we want fatal error if stat fails on the
presumed pathname.
|
|
The value of the variable is passed to stat(2)
and st_mtime is new value.
An optional arg can be used if stat(2) fails, otherwise
the current time is used.
See varmod-mtime.mk for usage examples.
|
|
This allows ${%Y:L:gmtime=${mtime}} instead of the indirect
${%Y:L:${:Ugmtime=${mtime}}}.
The direct form also prevents any ':' from the nested expression to be
interpreted as a separator, which doesn't matter for the ':gmtime' and
':localtime' modifiers but will prove useful for other modifiers that
follow the same pattern.
|
|
No functional change.
|
|
Since var.c 1.925 from 2021-04-12.
|
|
Since var.c 1.323 from 2020-07-26, modifiers containing unbalanced
braces or parentheses were parsed differently, depending on whether they
were relevant or not.
For example, the expression '${VAR:...}' is enclosed with braces. When
this expression has a modifier ':S,},}},g' that would double each '}' in
that expression, the parser got confused:
If the expression was relevant, the modifier was parsed as usual, taking
into account that the 3 '}' in the modifier are ordinary characters.
If the expression was irrelevant, the parser only counted the '{' and
the '}', without taking into account that a '}' might be escaped by a
'\' or be an ordinary character. Parsing therefore stopped at the first
'}', assuming it would finish the expression '${VAR:S,}'.
This parsing mode of only counting balanced '{' and '}' makes sense for
the modifier ':@var@...@', which expands each word of the expression
using the template from the '...'. These templates tend to be simple
enough that counting the '{' and '}' suffices.
|
|
The variable name '.MAKEOVERRIDES' was already used in the non-macro
form.
No binary change.
|
|
The variable name is distinctive enough to be searched directly in the
code instead of having a named constant for it.
No binary change.
|
|
No functional change.
|
|
None of the calls to Var_Subst used the return value, and the return
value was always VPR_OK.
No functional change.
|
|
No functional change.
|
|
No functional change.
|
|
Conditionals evaluate vars with SCOPE_CMDLINE, if :_
is used within a conditional expression and is thus
set in SCOPE_CMDLINE, it breaks any use of :_ in SCOPE_GLOBAL.
The simplest solution is for :_ to always use SCOPE_GLOBAL
Reviewed by: rillig
|
|
Make variables like .newline and .MAKE.{GID,PID,PPID,UID} read-only.
Reviewed by: rillig
|
|
|
|
Reviewed by: rillig
|
|
No binary change.
|
|
No functional change.
|
|
No functional change.
|
|
No binary change on x86_64.
|
|
A modifier in an expression ends not only at the next ':' or at the
closing '}' or ')', but also at the end of the string.
Previously, testing for the end of the string had been done separately,
which was error-prone since 2006-05-11, when indirect modifiers were
introduced. Since then, it was possible that the string terminator '\0'
was accidentally skipped in cases where the loop condition only tested
for the ending character. When parsing indirect modifiers, the ending
character is indeed '\0', but when parsing direct modifiers, it is '}'
or ')'.
A welcome side effect is that in the case of unclosed expressions such
as '${VAR:Modifier', the amount of error messages is reduced from 2 or 3
to only 1. The removed error messages were wrong and thus confusing
anyway.
|
|
Since at least 2009-01-17, probably already since 2006-02-18, when
modifiers were allowed to be nested expressions.
|
|
Since 2000-04-29, when the ':D' and ':U' modifiers were added.
|
|
The modifier ':@var@body@' parses the body in parse-only mode and later
uses Var_Subst on it, in which each literal '$' must be written as '$$'.
Trying to parse the loop body using Var_Parse treated the text
'$${var:-0}' as a single '$' followed by the expression '${var:-0}',
wrongly complaining about the 'Unknown modifier "-0"'.
Found by sjg.
|
|
|
|
When parsing the expression ${:D any ${uninterpreted} text}, parsing of
the ':D' modifier only needs to skip to the next delimiter, there is no
need to keep record of the text that has been skipped. In this
particular example, there had been an unnecessary memory allocation
since the nested expression was not copied to the result buffer. Due to
that, the resulting buffer contained " any text", which was not a
substring of the text passed to the parser, thereby forcing the memory
allocation.
No functional change.
|
|
No functional change.
|
|
No binary change.
|
|
No functional change.
|
|
No functional change.
|
|
Determining the location where the error occurred is now done by
ParseVErrorInternal. This frees the remaining code from keeping the
filename and the line number together. It also makes Parse_Error short
enough that it might be worth providing a separate function for each of
the 3 log levels.
No functional change.
|
|
|
|
All instances of VarFind that could be replaced with VarFindSubstring
have been replaced.
|
|
|
|
Since trailing whitespace is invisible, describe the variable value in
words to make it visible.
|
|
These log messages are intended for human interpretation, so don't make
them unnecessarily hard to read.
|
|
When sorting the words of an expression numerically using the modifier
':On' (added on 2021-07-30), use 64-bit numbers even on 32-bit
platforms. A typical use case is comparing file sizes.
When tracing the execution of jobs, fix an integer overflow after 2038.
32-bit platforms that use a pre-C99 compiler still have this problem.
No change to the test suite since most tests simply skip any potential
differences between 32-bit platforms and 64-bit platforms (see
varmod-order-numeric.mk) or already account for both variants (see
varmod-localtime.mk).
|
|
|
|
|
|
No functional change.
|
|
At least on NetBSD, make cannot be fooled with an environment variable
having an empty name. When running '/usr/bin/env =undefined make', the
argument is parsed as a variable assignment, but putenv(3) refuses to
process an empty variable name. Calling execve(2) directly got a step
further, the kernel didn't filter '=undefined' from the environment
variables. But getenv(3) always returns NULL when querying the
environment variable with the empty name.
On other operating systems, things may be different. Trying to set an
environment variable with an empty name may cause errors in env(1),
putenv(3), execve(2), getenv(3) or other places, so don't add an
automatic test for now.
|
|
No functional change.
|
|
No binary change.
|