1# $NetBSD: cond-short.mk,v 1.18 2021/12/12 09:49:09 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 variable expressions and only 13# parse them. They were still evaluated though, the only difference to 14# relevant variable expressions was that in the irrelevant variable 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 it still evaluated the 18# expression, even though the expression was irrelevant. 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 does 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. 126 127.if 0 128. if ${echo "unexpected nested and" 1>&2 :L:sh} 129. endif 130.endif 131 132.if 1 133.elif ${echo "unexpected nested or" 1>&2 :L:sh} 134.endif 135 136# make sure these do not cause complaint 137#.MAKEFLAGS: -dc 138 139# TODO: Rewrite this whole section and check all the conditions and variables. 140# Several of the assumptions are probably wrong here. 141# TODO: replace 'x=' with '.info' or '.error'. 142V42= 42 143iV1= ${V42} 144iV2= ${V66} 145 146.if defined(V42) && ${V42} > 0 147x= Ok 148.else 149x= Fail 150.endif 151x!= echo 'defined(V42) && $${V42} > 0: $x' >&2; echo 152 153# With cond.c 1.76 from 2020-07-03, the following condition triggered a 154# warning: "String comparison operator should be either == or !=". 155# This was because the variable expression ${iV2} was defined, but the 156# contained variable V66 was undefined. The left-hand side of the comparison 157# therefore evaluated to the string "${V66}", which is obviously not a number. 158# 159# This was fixed in cond.c 1.79 from 2020-07-09 by not evaluating irrelevant 160# comparisons. Instead, they are only parsed and then discarded. 161# 162# At that time, there was not enough debug logging to see the details in the 163# -dA log. To actually see it, add debug logging at the beginning and end of 164# Var_Parse. 165.if defined(V66) && ( ${iV2} < ${V42} ) 166x= Fail 167.else 168x= Ok 169.endif 170# XXX: This condition doesn't match the one above. The quotes are missing 171# above. This is a crucial detail since without quotes, the variable 172# expression ${iV2} evaluates to "${V66}", and with quotes, it evaluates to "" 173# since undefined variables are allowed and expand to an empty string. 174x!= echo 'defined(V66) && ( "$${iV2}" < $${V42} ): $x' >&2; echo 175 176.if 1 || ${iV1} < ${V42} 177x= Ok 178.else 179x= Fail 180.endif 181x!= echo '1 || $${iV1} < $${V42}: $x' >&2; echo 182 183# With cond.c 1.76 from 2020-07-03, the following condition triggered a 184# warning: "String comparison operator should be either == or !=". 185# This was because the variable expression ${iV2} was defined, but the 186# contained variable V66 was undefined. The left-hand side of the comparison 187# therefore evaluated to the string "${V66}", which is obviously not a number. 188# 189# This was fixed in cond.c 1.79 from 2020-07-09 by not evaluating irrelevant 190# comparisons. Instead, they are only parsed and then discarded. 191# 192# At that time, there was not enough debug logging to see the details in the 193# -dA log. To actually see it, add debug logging at the beginning and end of 194# Var_Parse. 195.if 1 || ${iV2:U2} < ${V42} 196x= Ok 197.else 198x= Fail 199.endif 200x!= echo '1 || $${iV2:U2} < $${V42}: $x' >&2; echo 201 202# the same expressions are fine when the lhs is expanded 203# ${iV1} expands to 42 204.if 0 || ${iV1} <= ${V42} 205x= Ok 206.else 207x= Fail 208.endif 209x!= echo '0 || $${iV1} <= $${V42}: $x' >&2; echo 210 211# ${iV2:U2} expands to 2 212.if 0 || ${iV2:U2} < ${V42} 213x= Ok 214.else 215x= Fail 216.endif 217x!= echo '0 || $${iV2:U2} < $${V42}: $x' >&2; echo 218 219# The right-hand side of the '&&' is irrelevant since the left-hand side 220# already evaluates to false. Before cond.c 1.79 from 2020-07-09, it was 221# expanded nevertheless, although with a small modification: undefined 222# variables may be used in these expressions without generating an error. 223.if defined(UNDEF) && ${UNDEF} != "undefined" 224. error 225.endif 226 227 228# Ensure that irrelevant conditions do not influence the result of the whole 229# condition. As of cond.c 1.302 from 2021-12-11, an irrelevant function call 230# evaluates to true (see CondParser_FuncCall and CondParser_FuncCallEmpty), an 231# irrelevant comparison evaluates to false (see CondParser_Comparison). 232# 233# An irrelevant true bubbles up to the outermost CondParser_And, where it is 234# ignored. An irrelevant false bubbles up to the outermost CondParser_Or, 235# where it is ignored. 236# 237# If the condition parser should ever be restructured, the bubbling up of the 238# irrelevant evaluation results might show up accidentally. Prevent this. 239DEF= defined 240.undef UNDEF 241 242.if 0 && defined(DEF) 243. error 244.endif 245 246.if 1 && defined(DEF) 247.else 248. error 249.endif 250 251.if 0 && defined(UNDEF) 252. error 253.endif 254 255.if 1 && defined(UNDEF) 256. error 257.endif 258 259.if 0 || defined(DEF) 260.else 261. error 262.endif 263 264.if 1 || defined(DEF) 265.else 266. error 267.endif 268 269.if 0 || defined(UNDEF) 270. error 271.endif 272 273.if 1 || defined(UNDEF) 274.else 275. error 276.endif 277 278 279all: 280