1# $NetBSD: cond-short.mk,v 1.23 2023/11/19 22:32:44 rillig Exp $ 2# 3# Demonstrates that in conditions, the right-hand side of an && or || 4# is only evaluated if it can actually influence the result. 5# This is called 'short-circuit evaluation' and is the usual evaluation 6# mode in most programming languages. A notable exception is Ada, which 7# distinguishes between the operators 'And', 'And Then', 'Or', 'Or Else'. 8# 9# Before 2020-06-28, the right-hand side of an && or || operator was always 10# evaluated, which was wrong. In cond.c 1.69 and var.c 1.197 on 2015-10-11, 11# Var_Parse got a new parameter named 'wantit'. Since then it would have been 12# possible to skip evaluation of irrelevant expressions and only 13# parse them. They were still evaluated though, the only difference to 14# relevant expressions was that in the irrelevant 15# expressions, undefined variables were allowed. This allowed for conditions 16# like 'defined(VAR) && ${VAR:S,from,to,} != ""', which no longer produced an 17# error message 'Malformed conditional', but the irrelevant expression was 18# still evaluated. 19# 20# Since the initial commit on 1993-03-21, the manual page has been saying that 21# make 'will only evaluate a conditional as far as is necessary to determine', 22# but that was wrong. The code in cond.c 1.1 from 1993-03-21 looks good since 23# it calls Var_Parse(condExpr, VAR_CMD, doEval,&varSpecLen,&doFree), but the 24# definition of Var_Parse did not call the third parameter 'doEval', as would 25# be expected, but instead 'err', accompanied by the comment 'TRUE if 26# undefined variables are an error'. This subtle difference between 'do not 27# evaluate at all' and 'allow undefined variables' led to the unexpected 28# evaluation. 29# 30# See also: 31# var-eval-short.mk, for short-circuited variable modifiers 32 33# The && operator: 34 35.if 0 && ${echo "unexpected and" 1>&2 :L:sh} 36.endif 37 38.if 1 && ${echo "expected and" 1>&2 :L:sh} 39.endif 40 41.if 0 && exists(nonexistent${echo "unexpected and exists" 1>&2 :L:sh}) 42.endif 43 44.if 1 && exists(nonexistent${echo "expected and exists" 1>&2 :L:sh}) 45.endif 46 47.if 0 && empty(${echo "unexpected and empty" 1>&2 :L:sh}) 48.endif 49 50.if 1 && empty(${echo "expected and empty" 1>&2 :L:sh}) 51.endif 52 53# "VAR U11" is not evaluated; it was evaluated before 2020-07-02. 54# The whole !empty condition is only parsed and then discarded. 55VAR= ${VAR${:U11${echo "unexpected VAR U11" 1>&2 :L:sh}}} 56VAR13= ${VAR${:U12${echo "unexpected VAR13" 1>&2 :L:sh}}} 57.if 0 && !empty(VAR${:U13${echo "unexpected U13 condition" 1>&2 :L:sh}}) 58.endif 59 60VAR= ${VAR${:U21${echo "unexpected VAR U21" 1>&2 :L:sh}}} 61VAR23= ${VAR${:U22${echo "expected VAR23" 1>&2 :L:sh}}} 62.if 1 && !empty(VAR${:U23${echo "expected U23 condition" 1>&2 :L:sh}}) 63.endif 64VAR= # empty again, for the following tests 65 66# The :M modifier is only parsed, not evaluated. 67# Before 2020-07-02, it was wrongly evaluated. 68.if 0 && !empty(VAR:M${:U${echo "unexpected M pattern" 1>&2 :L:sh}}) 69.endif 70 71.if 1 && !empty(VAR:M${:U${echo "expected M pattern" 1>&2 :L:sh}}) 72.endif 73 74.if 0 && !empty(VAR:S,from,${:U${echo "unexpected S modifier" 1>&2 :L:sh}},) 75.endif 76 77.if 0 && !empty(VAR:C,from,${:U${echo "unexpected C modifier" 1>&2 :L:sh}},) 78.endif 79 80.if 0 && !empty("" == "" :? ${:U${echo "unexpected ? modifier" 1>&2 :L:sh}} :) 81.endif 82 83.if 0 && !empty(VAR:old=${:U${echo "unexpected = modifier" 1>&2 :L:sh}}) 84.endif 85 86.if 0 && !empty(1 2 3:L:@var@${:U${echo "unexpected @ modifier" 1>&2 :L:sh}}@) 87.endif 88 89.if 0 && !empty(:U${:!echo "unexpected exclam modifier" 1>&2 !}) 90.endif 91 92# Irrelevant assignment modifiers are skipped as well. 93.if 0 && ${1 2 3:L:@i@${FIRST::?=$i}@} 94.endif 95.if 0 && ${1 2 3:L:@i@${LAST::=$i}@} 96.endif 97.if 0 && ${1 2 3:L:@i@${APPENDED::+=$i}@} 98.endif 99.if 0 && ${echo.1 echo.2 echo.3:L:@i@${RAN::!=${i:C,.*,&; & 1>\&2,:S,., ,g}}@} 100.endif 101.if defined(FIRST) || defined(LAST) || defined(APPENDED) || defined(RAN) 102. warning first=${FIRST} last=${LAST} appended=${APPENDED} ran=${RAN} 103.endif 104 105# The || operator: 106 107.if 1 || ${echo "unexpected or" 1>&2 :L:sh} 108.endif 109 110.if 0 || ${echo "expected or" 1>&2 :L:sh} 111.endif 112 113.if 1 || exists(nonexistent${echo "unexpected or exists" 1>&2 :L:sh}) 114.endif 115 116.if 0 || exists(nonexistent${echo "expected or exists" 1>&2 :L:sh}) 117.endif 118 119.if 1 || empty(${echo "unexpected or empty" 1>&2 :L:sh}) 120.endif 121 122.if 0 || empty(${echo "expected or empty" 1>&2 :L:sh}) 123.endif 124 125# Unreachable nested conditions are skipped completely as well. These skipped 126# lines may even contain syntax errors. This allows to skip syntactically 127# incompatible new features in older versions of make. 128 129.if 0 130. if ${echo "unexpected nested and" 1>&2 :L:sh} 131. endif 132.endif 133 134.if 1 135.elif ${echo "unexpected nested or" 1>&2 :L:sh} 136.endif 137 138 139NUMBER= 42 140INDIR_NUMBER= ${NUMBER} 141INDIR_UNDEF= ${UNDEF} 142 143.if defined(NUMBER) && ${NUMBER} > 0 144.else 145. error 146.endif 147 148# Starting with var.c 1.226 from from 2020-07-02, the following condition 149# triggered a warning: "String comparison operator should be either == or !=". 150# 151# The left-hand side of the '&&' evaluated to false, which should have made 152# the right-hand side irrelevant. 153# 154# On the right-hand side of the '&&', the expression ${INDIR_UNDEF} was 155# defined and had the value '${UNDEF}', but the nested variable UNDEF was 156# undefined. The right hand side "${INDIR_UNDEF}" still needed to be parsed, 157# and in parse-only mode, the "value" of the parsed expression was the 158# uninterpreted variable value, in this case '${UNDEF}'. And even though the 159# right hand side of the '&&' should have been irrelevant, the two sides of 160# the comparison were still parsed and evaluated. Comparing these two values 161# numerically was not possible since the string '${UNDEF}' is not a number, 162# so the comparison fell back to string comparison, which then complained 163# about the '>' operator. 164# 165# This was fixed in cond.c 1.79 from 2020-07-09 by not evaluating irrelevant 166# comparisons. Instead, they are only parsed and then discarded. 167# 168# At that time, there was not enough debug logging to see the details in the 169# -dA log. To actually see it, add debug logging at the beginning and end of 170# Var_Parse. 171.if defined(UNDEF) && ${INDIR_UNDEF} < ${NUMBER} 172. error 173.endif 174# Adding a ':U' modifier to the irrelevant expression didn't help, as that 175# expression was only parsed, not evaluated. The resulting literal string 176# '${INDIR_UNDEF:U2}' was not numeric either, for the same reason as above. 177.if defined(UNDEF) && ${INDIR_UNDEF:U2} < ${NUMBER} 178. error 179.endif 180 181 182# Since cond.c 1.76 from 2020.06.28 and before var.c 1.225 from 2020.07.01, 183# the following snippet resulted in the error message 'Variable VAR is 184# recursive'. The condition '0' evaluated to false, which made the right-hand 185# side of the '&&' irrelevant. Back then, irrelevant condition parts were 186# still evaluated, but in "irrelevant mode", which allowed undefined variables 187# to occur in expressions. In this mode, the variable name 'VAR' was 188# unnecessarily evaluated, resulting in the expression '${VAR${:U1}}'. In 189# this expression, the variable name was 'VAR${:U1}', and of this variable 190# name, only the fixed part 'VAR' was evaluated, without the part '${:U1}'. 191# This partial evaluation led to the wrong error message about 'VAR' being 192# recursive. 193VAR= ${VAR${:U1}} 194.if 0 && !empty(VAR) 195.endif 196 197 198# Enclosing the expression in double quotes changes how that expression is 199# evaluated. In irrelevant expressions that are enclosed in double quotes, 200# expressions based on undefined variables are allowed and evaluate to an 201# empty string. 202# 203# The manual page stated from at least 1993 on that irrelevant conditions were 204# not evaluated, but that was wrong. These conditions were evaluated, the 205# only difference was that undefined variables in them didn't trigger an 206# error. Since numeric conditions are quite rare, this subtle difference 207# didn't catch much attention, as most other conditions such as pattern 208# matches or equality comparisons worked fine and never produced error 209# messages. 210.if defined(UNDEF) && "${INDIR_UNDEF}" < ${NUMBER} 211. error 212.endif 213 214# Since the condition is relevant, the indirect undefined variable is 215# evaluated as usual, resolving nested undefined expressions to an empty 216# string. 217# 218# Comparing an empty string numerically is not possible, however, make has an 219# ugly hack in TryParseNumber that treats an empty string as a valid numerical 220# value, thus hiding bugs in the makefile. 221.if ${INDIR_UNDEF} < ${NUMBER} 222# only due to the ugly hack 223.else 224. error 225.endif 226 227# Due to the quotes around the left-hand side of the '<', the operand is 228# marked as a string, thus preventing a numerical comparison. 229# 230# expect+1: Comparison with '<' requires both operands '' and '42' to be numeric 231.if "${INDIR_UNDEF}" < ${NUMBER} 232. info yes 233.else 234. info no 235.endif 236 237# The right-hand side of '||' is irrelevant and thus not evaluated. 238.if 1 || ${INDIR_NUMBER} < ${NUMBER} 239.else 240. error 241.endif 242 243# The right-hand side of '||' is relevant and thus evaluated normally. 244.if 0 || ${INDIR_NUMBER} < ${NUMBER} 245. error 246.endif 247 248# The right-hand side of '||' evaluates to an empty string, as the variable 249# 'INDIR_UNDEF' is defined, therefore the modifier ':U2' has no effect. 250# Comparing an empty string numerically is not possible, however, make has an 251# ugly hack in TryParseNumber that treats an empty string as a valid numerical 252# value, thus hiding bugs in the makefile. 253.if 0 || ${INDIR_UNDEF:U2} < ${NUMBER} 254# only due to the ugly hack 255.else 256. error 257.endif 258 259 260# The right-hand side of the '&&' is irrelevant since the left-hand side 261# already evaluates to false. Before cond.c 1.79 from 2020-07-09, it was 262# expanded nevertheless, although with a small modification: undefined 263# variables may be used in these expressions without generating an error. 264.if defined(UNDEF) && ${UNDEF} != "undefined" 265. error 266.endif 267 268 269# Ensure that irrelevant conditions do not influence the result of the whole 270# condition. As of cond.c 1.302 from 2021-12-11, an irrelevant function call 271# evaluated to true (see CondParser_FuncCall and CondParser_FuncCallEmpty), an 272# irrelevant comparison evaluated to false (see CondParser_Comparison). 273# 274# An irrelevant true bubbles up to the outermost CondParser_And, where it is 275# ignored. An irrelevant false bubbles up to the outermost CondParser_Or, 276# where it is ignored. 277# 278# If the condition parser should ever be restructured, the bubbling up of the 279# irrelevant evaluation results might show up accidentally. Prevent this. 280DEF= defined 281.undef UNDEF 282 283.if 0 && defined(DEF) 284. error 285.endif 286 287.if 1 && defined(DEF) 288.else 289. error 290.endif 291 292.if 0 && defined(UNDEF) 293. error 294.endif 295 296.if 1 && defined(UNDEF) 297. error 298.endif 299 300.if 0 || defined(DEF) 301.else 302. error 303.endif 304 305.if 1 || defined(DEF) 306.else 307. error 308.endif 309 310.if 0 || defined(UNDEF) 311. error 312.endif 313 314.if 1 || defined(UNDEF) 315.else 316. error 317.endif 318 319 320all: 321