From stijn@pcwin002.win.tue.nl  Tue Feb 19 07:47:40 2002
Return-Path: <stijn@pcwin002.win.tue.nl>
Received: from pcwin002.win.tue.nl (pcwin002.win.tue.nl [131.155.71.72])
	by hub.freebsd.org (Postfix) with ESMTP id 2509E37B400
	for <FreeBSD-gnats-submit@freebsd.org>; Tue, 19 Feb 2002 07:47:39 -0800 (PST)
Received: (from stijn@localhost)
	by pcwin002.win.tue.nl (8.11.6/8.11.4) id g1JFlcm41029;
	Tue, 19 Feb 2002 16:47:38 +0100 (CET)
	(envelope-from stijn)
Message-Id: <200202191547.g1JFlcm41029@pcwin002.win.tue.nl>
Date: Tue, 19 Feb 2002 16:47:38 +0100 (CET)
From: stijn@win.tue.nl
Reply-To: stijn@win.tue.nl
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: make(1) variable modifier bug (:L, :U etc)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         35119
>Category:       bin
>Synopsis:       make(1) variable modifier bug (:L, :U etc)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 19 07:50:01 PST 2002
>Closed-Date:    Tue Feb 19 14:42:01 PST 2002
>Last-Modified:  Tue Feb 19 14:44:58 PST 2002
>Originator:     Stijn Hoop
>Release:        FreeBSD 4.5-RC
>Organization:
>Environment:

System: FreeBSD 4.5-RC #0: Wed Jan 16 04:30:08 CET 2002

>Description:

make(1) has a buglet wrt expanding variables with modifiers. If an expansion
of an undefined variable, with a modifier, is used in an .if statement like so:

.if defined(FOO) && ${FOO:L} == "bar"

make bombs out with a 'Malformed conditional', even if FOO is not defined.

An expansion like this works correctly in the non-modified case:

.if defined(FOO) && ${FOO} == "bar"

performs as expected.

>How-To-Repeat:

Extract the following Makefile to an empty directory and type 'make'. Witness
make bombing out.

--- /dev/null	Tue Feb 19 16:40:07 2002
+++ Makefile	Tue Feb 19 16:44:15 2002
@@ -0,0 +1,23 @@
+all:
+	${MAKE} -DTEST_1 result
+	${MAKE} -DTEST_2 result
+
+.if defined(TEST_1)
+.if defined(FOO) && ${FOO} != "bar"
+result:
+	@echo "FOO != bar"
+.else
+result:
+	@echo "FOO undefined or == bar"
+.endif
+.endif
+
+.if defined(TEST_2)
+.if defined(FOO) && ${FOO:L} != "bar"
+result:
+	@echo "FOO != bar (with case permutation)"
+.else
+result:
+	@echo "FOO undefined or == bar (with case permutation)"
+.endif
+.endif

>Fix:

Unfortunately not available; hacking make is beyond me...
>Release-Note:
>Audit-Trail:

From: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx>
To: stijn@win.tue.nl
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/35119: make(1) variable modifier bug (:L, :U etc)
Date: Tue, 19 Feb 2002 21:42:30 +0100

 --OFN=.KLuoT/o68,X
 Content-Type: text/plain; charset=US-ASCII
 Content-Transfer-Encoding: 7bit
 
 On Tue, 19 Feb 2002 16:47:38 +0100 (CET) stijn@win.tue.nl wrote:
 
 > make(1) has a buglet wrt expanding variables with modifiers. If an
 > expansion of an undefined variable, with a modifier, is used in an .if
 > statement like so:
 > 
 > .if defined(FOO) && ${FOO:L} == "bar"
 > 
 > make bombs out with a 'Malformed conditional', even if FOO is not
 > defined.
 
 i believe this is already known. make processes all statements on an .if line, no matter if this is needed or not (unlike most other languages):
 
 ..if defined(FOO) && ${FOO} == "bar"
 will result in the following (without having FOO defined):
 res1 := test FOO for existance = false
 res2 := test FOO == "bar" = false
 
 res := res1 && res2 == false
 
 if you use a modifier, make will (of course [knowing the fact above]) complain about the variable not being assigned.
 
 Fix:
 
 ..if defined(FOO)
 ..if ${FOO:L} == "bar"
 
 ..endif
 ..endif
 
 so it's got nothing to do with defined() and the modifiers, more with the way make processes conditionals.
 
 cheerz
   corecode
 
 
 -- 
 /"\   http://corecode.ath.cx/
 \ /
  \     ASCII Ribbon Campaign
 / \  Against HTML Mail and News
 
 --OFN=.KLuoT/o68,X
 Content-Type: application/pgp-signature
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.0.6 (FreeBSD)
 
 iD8DBQE8cri9r5S+dk6z85oRAmEXAJ9+NdS8HmbX1oN1nUGI7aqS8DIS3QCcCUZz
 Hv0zwITEM3CMRoZHw+2D8oc=
 =mrj0
 -----END PGP SIGNATURE-----
 
 --OFN=.KLuoT/o68,X--
 

From: "Crist J. Clark" <cjc@FreeBSD.ORG>
To: "Simon 'corecode' Schubert" <corecode@corecode.ath.cx>
Cc: bug-followup@FreeBSD.ORG
Subject: Re: bin/35119: make(1) variable modifier bug (:L, :U etc)
Date: Tue, 19 Feb 2002 14:33:41 -0800

 On Tue, Feb 19, 2002 at 12:50:02PM -0800, Simon 'corecode' Schubert wrote:
 >  On Tue, 19 Feb 2002 16:47:38 +0100 (CET) stijn@win.tue.nl wrote:
 >  
 >  > make(1) has a buglet wrt expanding variables with modifiers. If an
 >  > expansion of an undefined variable, with a modifier, is used in an .if
 >  > statement like so:
 >  > 
 >  > .if defined(FOO) && ${FOO:L} == "bar"
 >  > 
 >  > make bombs out with a 'Malformed conditional', even if FOO is not
 >  > defined.
 >  
 >  i believe this is already known. make processes all statements on an .if line, no matter if this is needed or not (unlike most other languages):
 
 The problem is that this behavior contradicts the documented
 behavior. make(1) says,
 
      As in C, make will only evaluate a conditional as far as is necessary to
      determine its value.
 
 But as you say, this is known behavior, PR bin/34032. A patch is
 included in that PR's audit trail. Would the submitter please check if
 that patch solve's his problems? I'm looking to commit that
 soon, but not 100% sure the logic is totally sound. Another successful
 test would help. Thanks.
 
 I will close up this PR as a duplicate.
 -- 
 Crist J. Clark                     |     cjclark@alum.mit.edu
                                    |     cjclark@jhu.edu
 http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
State-Changed-From-To: open->closed 
State-Changed-By: cjc 
State-Changed-When: Tue Feb 19 14:42:01 PST 2002 
State-Changed-Why:  
Duplicate of problem reported in bin/34032. The audit trail of that PR 
contains a patch being evaluated at the time this PR was 
closed. Please see the audit trail of PR bin/34032 for the current 
status of this bug. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=35119 
>Unformatted:
