[net.bugs.v7] Ritchie C compiler bug fix

hugh@hcrvx1.UUCP (Hugh Redelmeier) (07/04/85)

.

When an int value is required of an expression, but the expression
is a post-increment or -decrement of a long variable, only the
low-order half of the long is incremented or decremented.

Look at the code for
	long x;
	main() { (int) (x++); }
The cast is the simplest form, but a[x++] generates bad code too.

The fix is to change c10.c, routine ncopy().  This routine is
used to copy a node that is subject to post inc/dec when it
might be modified by the "user" of the result.  The code thinks
that only REG nodes are at risk, but so too are NAME nodes of
type LONG.  The test must be changed, and so must the node
copying logic (a REG node is different from a NAME node).

keenan@inmet.UUCP previously reported this bug (net.bugs.2bsd, May 28):
> Here is a small program that demonstrates what I think is a bug in the
> BSD2.9 C compiler. I guess its not appropriate to use a long as the
> index to an array, but it should just be cast to an integer, and not
> affect the postdecrement. Instead the decrement treats the variable as
> an integer.  The results are also presented. Is this a bug, or is my
> code just incorrect?
> 
> #include <stdio.h>
> int arr[100];
> int x;
> long p_end;
> main()
> {
>   printf("Autodecrement inside array reference\n");
>   p_end = 0l;
>   printf("before %ld\n", p_end);
>   x = arr[p_end--];
>   printf("after %ld\n", p_end);
> }
> 
> ++++++++++++++++++++++++++ OUTPUT +++++++++++++++++++++++++
> Autodecrement inside array reference
> before 0
> after 65535
> 
> --keenan ross		UUCP:     {bellcore,ihnp4}!inmet!keenan
>  Intermetrics, Inc.	INTERNET: ima!inmet!keenan@CCA-UNIX.ARPA
>  733 Concord Ave.
>  Cambridge, MA  02138	PHONE:    (617) 661-1840

Hugh Redelmeier (416) 922-1937
{utzoo, ihnp4, decvax}!hcr!hugh