>Number:         2097
>Category:       bin
>Synopsis:       (x || y) may be 1 when x and y are both 0.
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Feb 18 14:20:00 1996
>Last-Modified:
>Originator:     Peter Seebach
>Organization:
Usenet Fact Police (Undercover)
>Release:        Feb 17 96
>Environment:
System: NetBSD taniemarie 1.1A NetBSD 1.1A (SEEBS) #0: Mon Jan 15 20:07:46 CST 1996 seebs@taniemarie:/usr/src/sys/arch/amiga/compile/SEEBS amiga


>Description:
	I discovered that lint was spuriously reporting integer constant too
	large.  The following simple program produces the problem:

>How-To-Repeat:
	Study lint's behavior, and dissect code in cgram.y.
>Fix:
	I have *no* clue.  Adding ()'s around the operands of the || does
	not change the result, so it's not a precedence handling problem.
>Audit-Trail:
>Unformatted:
>enum foo {
>	BAR,
>	BAZ,
>	QUUX = BAZ << 1
>};
>
>int i = QUUX;

	lint run on this spuriously complains that the integer constant is
	too large.

	Where's the code generation bug?

	I added the following to cgram.y:
fprintf(stderr, "!utyp - > %d, < %d - || %d\n",
        (v->v_quad > (quad_t) INT_MAX),
	(v->v_quad < (quad_t) INT_MIN),
	(v->v_quad > (quad_t) INT_MAX || v->v_quad < (quad_t) INT_MIN));

...
I get
	!utyp - > 0, < 0 - || 1
from this.

Above that, I have:
fprintf(stderr, "quad %qd (%d as int) > %lu ? %d\n",
        (quad_t) v->v_quad, i, (unsigned long) INT_MAX,
	((unsigned long) v->v_quad > (unsigned long) INT_MAX));
which says:
	quad 2 (2 as int) > 2147483647 ? 0

	It seems to be clear that 2 is within [INT_MIN,INT_MAX] pretty
	comfortably.

	I cannot figure out why this doesn't happen if the value QUUX is
	simply created as 2, but only if it's created by a <<.

	My concern about the code generation is simply that, to the best
	of my knowledge, the 3rd result of that 1st printf up there *cannot*
	be correct.