aboutsummaryrefslogtreecommitdiff
path: root/contrib/bmake/unit-tests/cond-op-parentheses.mk
blob: b6c9bd3c0e9ddb3be35da094957c7708a203363d (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
# $NetBSD: cond-op-parentheses.mk,v 1.7 2023/06/01 20:56:35 rillig Exp $
#
# Tests for parentheses in .if conditions, which group expressions to override
# the precedence of the operators '!', '&&' and '||'.  Parentheses cannot be
# used to form arithmetic expressions such as '(3+4)' though.

# Contrary to the C family of programming languages, the outermost condition
# does not have to be enclosed in parentheses.
.if defined(VAR)
.  error
.elif !1
.  error
.endif

# Parentheses cannot enclose numbers as there is no need for it.  Make does
# not implement any arithmetic functions in its condition parser.  If
# absolutely necessary, use expr(1).
#
# XXX: It's inconsistent that the right operand has unbalanced parentheses.
#
# expect+1: Comparison with '>' requires both operands '3' and '(2' to be numeric
.if 3 > (2)
.endif
# expect+1: Malformed conditional ((3) > 2)
.if (3) > 2
.endif

# Test for deeply nested conditions.
.if	((((((((((((((((((((((((((((((((((((((((((((((((((((((((	\
	((((((((((((((((((((((((((((((((((((((((((((((((((((((((	\
	1								\
	))))))))))))))))))))))))))))))))))))))))))))))))))))))))	\
	))))))))))))))))))))))))))))))))))))))))))))))))))))))))
# Parentheses can be nested at least to depth 112.  There is nothing special
# about this number though, much higher numbers work as well, at least on
# NetBSD.  The actual limit depends on the allowed call stack depth for C code
# of the platform.  Anyway, 112 should be enough for all practical purposes.
.else
.  error
.endif

# An unbalanced opening parenthesis is a parse error.
# expect+1: Malformed conditional (()
.if (
.  error
.else
.  error
.endif

# An unbalanced closing parenthesis is a parse error.
#
# Before cond.c 1.237 from 2021-01-19, CondParser_Term returned TOK_RPAREN
# even though the documentation of that function promised to only ever return
# TOK_TRUE, TOK_FALSE or TOK_ERROR.  In cond.c 1.241, the return type of that
# function was changed to a properly restricted enum type, to prevent this bug
# from occurring again.
# expect+1: Malformed conditional ())
.if )
.  error
.else
.  error
.endif

all:
	@:;