bin/50960: /bin/sh generates incorrect value for && and || inside $(( ))

[kre%munnari.OZ.AU@localhost]

>Number:         50960
>Category:       bin
>Synopsis:       /bin/sh generates incorrect value for && and || inside $(( ))
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 12 20:55:00 +0000 2016
>Originator:     Robert Elz
>Release:        NetBSD 7.99.26 (all up to date of this PR)
>Organization:
>Environment:
System: NetBSD andromeda.noi.kre.to 7.99.26 NetBSD 7.99.26 (VBOX64-1.1-20160128) #43: Thu Jan 28 16:09:08 ICT 2016 kre%onyx.coe.psu.ac.th@localhost:/usr/obj/current/kernels/amd64/VBOX64 amd64
Architecture: x86_64
Machine: amd64
>Description:
	The logical && and || operators are supposed to generate a boolean
	value (which should be 0 for false and 1 for true, the same as
	is done in C).  Currently they generate 0 for false, ad non-zero
	for true (where the non-zero will be whichever of the operand
	values was decisive in determining the answer is not false, ie:
	the RHS for &&, or the LHS for ||).

	No other stell I have tested act like this, they all return 0 or 1
	in all cases.

	The ops are also  expected to do lazy evaluation, but inside the
	shell, this means very little (the shell calculates the results as
	a side effect of parsing the expression, so it all gets
	evaluated anyway).  While we have no operators with side-effects
	(no assignment operators - see PR bin/50958) this makes no
	difference at all.

	It will never happen (because of the rules of sh parsing and
	evaluation) that
		$(( 1 && $(some command that prints a number) ))
	will fail to execute the "some command..." part, that happens
	before the $(( )) expression parsing even starts,

>How-To-Repeat:
		bin/sh -c 'echo $(( 3 && 4 ))'
		4

		/bin/sh -c 'echo $(( 3 || 4 ))'
		3

	Other shells produce 1 in both cases.

	If the result is "false" the answer is 0, so most of the time this
	difference makes no difference, but it some expressions, it can.

>Fix:
	The fix is easy, and is implemented in my sources, however I will
	not submit a patch to change this in the master sources for /bin/sh
	in case there is something in the NetBSD tree which is depending
	upon this behaviour.

	We do not need to worry about externally sourced software, no-one
	else (I have tested anyway, which includes the FreeBSD shell,
	along with bash dash zsh pdksh and mksh) does what the NetBSD
	shell does, so nothing in the outside world will care.

	But there might be something buried in the NetBSD sources that
	does care, so I will leave this one pending a while to see if
	anyone knows of any case like that.