make(1): fix CRLF line endings in unit tests
This commit is contained in:
rillig
parent
fd2e38eaf1
commit
4ae53a3e65
@ -1,41 +1,41 @@
|
||||
# $NetBSD: dep-colon-bug-cross-file.mk,v 1.3 2020/09/25 23:42:43 rillig Exp $
|
||||
#
|
||||
# Until 2020-09-25, the very last dependency group of a top-level makefile
|
||||
# was not finished properly. This made it possible to add further commands
|
||||
# to that target.
|
||||
#
|
||||
# In pass 1, there is a dependency group at the bottom of the file.
|
||||
# This dependency group is not finished properly. Finishing the dependency
|
||||
# group would add the OP_HAS_COMMANDS flag to the "all" target, thereby
|
||||
# preventing any commands from being added later.
|
||||
#
|
||||
# After the file has been parsed completely, it is parsed again in pass 2.
|
||||
# In this pass, another command is added to the "current dependency group",
|
||||
# which was still the one from pass 1, which means it was possible to later
|
||||
# add commands to an existing target, even across file boundaries.
|
||||
#
|
||||
# Oops, even worse. Running this test in a make from 2020-09-25 or earlier
|
||||
# on NetBSD 8.0 x86_64 with MALLOC_OPTIONS=JA produces this or a similar
|
||||
# output:
|
||||
#
|
||||
# make: cannot open ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.
|
||||
#
|
||||
# The 'Z' means access to already freed memory; see jemalloc(3). The cause
|
||||
# for this is that in MainParseArgs, the command line arguments were not
|
||||
# properly copied before storing them in global variables.
|
||||
|
||||
PASS?= 1
|
||||
|
||||
.if ${PASS} == 2
|
||||
all:
|
||||
: pass 2
|
||||
.endif
|
||||
|
||||
.if ${PASS} == 1
|
||||
|
||||
PASS= 2
|
||||
.MAKEFLAGS: -f ${.PARSEDIR:q}/${.PARSEFILE:q}
|
||||
|
||||
all:
|
||||
: pass 1
|
||||
.endif
|
||||
# $NetBSD: dep-colon-bug-cross-file.mk,v 1.4 2020/09/27 09:53:41 rillig Exp $
|
||||
#
|
||||
# Until 2020-09-25, the very last dependency group of a top-level makefile
|
||||
# was not finished properly. This made it possible to add further commands
|
||||
# to that target.
|
||||
#
|
||||
# In pass 1, there is a dependency group at the bottom of the file.
|
||||
# This dependency group is not finished properly. Finishing the dependency
|
||||
# group would add the OP_HAS_COMMANDS flag to the "all" target, thereby
|
||||
# preventing any commands from being added later.
|
||||
#
|
||||
# After the file has been parsed completely, it is parsed again in pass 2.
|
||||
# In this pass, another command is added to the "current dependency group",
|
||||
# which was still the one from pass 1, which means it was possible to later
|
||||
# add commands to an existing target, even across file boundaries.
|
||||
#
|
||||
# Oops, even worse. Running this test in a make from 2020-09-25 or earlier
|
||||
# on NetBSD 8.0 x86_64 with MALLOC_OPTIONS=JA produces this or a similar
|
||||
# output:
|
||||
#
|
||||
# make: cannot open ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.
|
||||
#
|
||||
# The 'Z' means access to already freed memory; see jemalloc(3). The cause
|
||||
# for this is that in MainParseArgs, the command line arguments were not
|
||||
# properly copied before storing them in global variables.
|
||||
|
||||
PASS?= 1
|
||||
|
||||
.if ${PASS} == 2
|
||||
all:
|
||||
: pass 2
|
||||
.endif
|
||||
|
||||
.if ${PASS} == 1
|
||||
|
||||
PASS= 2
|
||||
.MAKEFLAGS: -f ${.PARSEDIR:q}/${.PARSEFILE:q}
|
||||
|
||||
all:
|
||||
: pass 1
|
||||
.endif
|
||||
|
||||
@ -1,64 +1,64 @@
|
||||
# $NetBSD: varparse-undef-partial.mk,v 1.1 2020/09/25 05:56:59 rillig Exp $
|
||||
|
||||
# When an undefined variable is expanded in a ':=' assignment, only the
|
||||
# initial '$' of the variable expression is skipped by the parser, while
|
||||
# the remaining expression is evaluated. In edge cases this can lead to
|
||||
# a completely different interpretation of the partially expanded text.
|
||||
|
||||
LIST= ${DEF} ${UNDEF} ${VAR.${PARAM}} end
|
||||
DEF= defined
|
||||
PARAM= :Q
|
||||
|
||||
# The expression ${VAR.{PARAM}} refers to the variable named "VAR.:Q",
|
||||
# with the ":Q" being part of the name. This variable is not defined,
|
||||
# therefore the initial '$' of that whole expression is skipped by the
|
||||
# parser (see Var_Subst, the Buf_AddByte in the else branch) and the rest
|
||||
# of the expression is expanded as usual.
|
||||
#
|
||||
# The resulting variable expression is ${VAR.:Q}, which means that the
|
||||
# interpretation of the ":Q" has changed from being part of the variable
|
||||
# name to being a variable modifier. This is a classical code injection.
|
||||
EVAL:= ${LIST}
|
||||
.if ${EVAL} != "defined end"
|
||||
. error ${EVAL}
|
||||
.endif
|
||||
|
||||
# Define the possible outcomes, to see which of them gets expanded.
|
||||
VAR.= var-dot without parameter
|
||||
${:UVAR.\:Q}= var-dot with parameter :Q
|
||||
|
||||
# At this point, the variable "VAR." is defined, therefore the expression
|
||||
# ${VAR.:Q} is expanded as usual.
|
||||
.if ${EVAL} != "defined var-dot\\ without\\ parameter end"
|
||||
. error ${EVAL}
|
||||
.endif
|
||||
|
||||
# In contrast to the previous line, evaluating the original LIST again now
|
||||
# produces a different result since the ":Q" has already been inserted
|
||||
# literally into the expression. The variable named "VAR.:Q" is defined,
|
||||
# therefore it is resolved as usual. The ":Q" is interpreted as part of the
|
||||
# variable name, as would be expected from reading the variable expression.
|
||||
EVAL:= ${LIST}
|
||||
.if ${EVAL} != "defined var-dot with parameter :Q end"
|
||||
. error ${EVAL}
|
||||
.endif
|
||||
|
||||
# It's difficult to decide what the best behavior is in this situation.
|
||||
# Should the whole expression be skipped for now, or should the inner
|
||||
# subexpressions be expanded already?
|
||||
#
|
||||
# Example 1:
|
||||
# CFLAGS:= ${CFLAGS:N-W*} ${COPTS.${COMPILER}}
|
||||
#
|
||||
# The variable COMPILER typically contains an identifier and the variable is
|
||||
# not modified later. In this practical case, it does not matter whether the
|
||||
# expression is expanded early, or whether the whole ${COPTS.${COMPILER}} is
|
||||
# expanded as soon as the variable COPTS.${COMPILER} becomes defined. The
|
||||
# expression ${COMPILER} would be expanded several times, but in this simple
|
||||
# scenario there would not be any side effects.
|
||||
#
|
||||
# TODO: Add a practical example where early/lazy expansion actually makes a
|
||||
# difference.
|
||||
|
||||
all:
|
||||
@:
|
||||
# $NetBSD: varparse-undef-partial.mk,v 1.2 2020/09/27 09:53:41 rillig Exp $
|
||||
|
||||
# When an undefined variable is expanded in a ':=' assignment, only the
|
||||
# initial '$' of the variable expression is skipped by the parser, while
|
||||
# the remaining expression is evaluated. In edge cases this can lead to
|
||||
# a completely different interpretation of the partially expanded text.
|
||||
|
||||
LIST= ${DEF} ${UNDEF} ${VAR.${PARAM}} end
|
||||
DEF= defined
|
||||
PARAM= :Q
|
||||
|
||||
# The expression ${VAR.{PARAM}} refers to the variable named "VAR.:Q",
|
||||
# with the ":Q" being part of the name. This variable is not defined,
|
||||
# therefore the initial '$' of that whole expression is skipped by the
|
||||
# parser (see Var_Subst, the Buf_AddByte in the else branch) and the rest
|
||||
# of the expression is expanded as usual.
|
||||
#
|
||||
# The resulting variable expression is ${VAR.:Q}, which means that the
|
||||
# interpretation of the ":Q" has changed from being part of the variable
|
||||
# name to being a variable modifier. This is a classical code injection.
|
||||
EVAL:= ${LIST}
|
||||
.if ${EVAL} != "defined end"
|
||||
. error ${EVAL}
|
||||
.endif
|
||||
|
||||
# Define the possible outcomes, to see which of them gets expanded.
|
||||
VAR.= var-dot without parameter
|
||||
${:UVAR.\:Q}= var-dot with parameter :Q
|
||||
|
||||
# At this point, the variable "VAR." is defined, therefore the expression
|
||||
# ${VAR.:Q} is expanded as usual.
|
||||
.if ${EVAL} != "defined var-dot\\ without\\ parameter end"
|
||||
. error ${EVAL}
|
||||
.endif
|
||||
|
||||
# In contrast to the previous line, evaluating the original LIST again now
|
||||
# produces a different result since the ":Q" has already been inserted
|
||||
# literally into the expression. The variable named "VAR.:Q" is defined,
|
||||
# therefore it is resolved as usual. The ":Q" is interpreted as part of the
|
||||
# variable name, as would be expected from reading the variable expression.
|
||||
EVAL:= ${LIST}
|
||||
.if ${EVAL} != "defined var-dot with parameter :Q end"
|
||||
. error ${EVAL}
|
||||
.endif
|
||||
|
||||
# It's difficult to decide what the best behavior is in this situation.
|
||||
# Should the whole expression be skipped for now, or should the inner
|
||||
# subexpressions be expanded already?
|
||||
#
|
||||
# Example 1:
|
||||
# CFLAGS:= ${CFLAGS:N-W*} ${COPTS.${COMPILER}}
|
||||
#
|
||||
# The variable COMPILER typically contains an identifier and the variable is
|
||||
# not modified later. In this practical case, it does not matter whether the
|
||||
# expression is expanded early, or whether the whole ${COPTS.${COMPILER}} is
|
||||
# expanded as soon as the variable COPTS.${COMPILER} becomes defined. The
|
||||
# expression ${COMPILER} would be expanded several times, but in this simple
|
||||
# scenario there would not be any side effects.
|
||||
#
|
||||
# TODO: Add a practical example where early/lazy expansion actually makes a
|
||||
# difference.
|
||||
|
||||
all:
|
||||
@:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user