Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!sri-unix!husc6!necntc!custom!boykin
From: boykin@custom.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: Bug in Microsoft C 4.00?
Message-ID: <506@custom.UUCP>
Date: Mon, 16-Feb-87 01:09:45 EST
Article-I.D.: custom.506
Posted: Mon Feb 16 01:09:45 1987
Date-Received: Mon, 16-Feb-87 18:46:09 EST
References: <216700008@orstcs.UUCP>
Organization: Custom Software Systems; Natick, MA
Lines: 33
Summary: Not a bug

In article <216700008@orstcs.UUCP>, go@orstcs.UUCP (go) writes:
> I don't know if anyone has reported this as a bug in this group, but here
> goes...
> In Microsoft C 4.00, (actually more a linker problem, but it's the linker
> supplied with the compiler) the linker can, in some cases, allocate
> memory to variables, such that the variables overlap.
... Extraneous stuff deleted
> int array1[100];
> 	printf("address of array1 is %x, end of array1 is %x\n",
> 		array1, array1+sizeof(array1));
> 
> 	printf("address of array2 is %x\n",
> 		array2);
> You will find that array2 is allocated somewhere
> within the limits of array1.

This is not a bug at all, but a misunderstanding of what happens
with 'sizeof' and pointer arithmetic.  Sizeof returns the number of BYTE's
of its operand.  For an integer array with 100 elements this will
be at least 200 (maybe 400, maybe more!).  When you add this value to 'array1'
(which is the address of the first element of the array,  you are
getting the address of the 200th (400th) element.  Array two then
appears to lie inside of array1, but in fact does not.  Hence, no
bug in MSC, just a little misunderstanding.

The reason the problem "goes away" when you initialize one of the arrays
is that initialized data gets dealth with slightly differently.  Under
UNIX(tm) this would be the data area, vs. the bss area of uninitialized
data.

Joe Boykin
Custom Software Systems
...{necntc, frog}!custom!boykin