From owner-freebsd-hackers Thu Apr 1 7:54:52 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 2E0F714E13 for ; Thu, 1 Apr 1999 07:54:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id HAA58192; Thu, 1 Apr 1999 07:54:29 -0800 (PST) (envelope-from dillon) Date: Thu, 1 Apr 1999 07:54:29 -0800 (PST) From: Matthew Dillon Message-Id: <199904011554.HAA58192@apollo.backplane.com> To: James Snow Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Curiosity Killed the Array References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :In working on a C program recently, I ran into some bugs, resolved them, :and then in resolving them realized that there isn't any run-time checking :of array boundaries. C does not do run time checking on array boundries. :void main( void ) { : int array[10]; : int i = 0; : while ( 1 == 1) { : array[i] = i; : print("%d\n", i); : i++; : } :} C will happily allow you to overflow the array. What is happening is that the array is allocated on the stack. You are overwriting portions of the stack outside the array. If you forward index the array, you are wiping out pieces of the stack used by the function and by callers of main. This will work until you hit the top of the stack. Of course, by that time you've pretty much corrupted the program's stack so you are dead meat anyway. If you reverse index the array, you are wiping out pieces of the stack used by the function and then delving down into empty space ... essentially writing new data into unused portions of the stack. This will work until you hit the maximum stack size the system allows (see 'limit'). The system will not allow your program to go outside its own private address space, but the system will of course allow the program to overwrite most portions of its own private address space. The system has no idea whether an access to a valid memory location within the program is on purpose or due to a bug in the program :-) :So, I'm just curious as to the technical reasons behind this. (If anyone :is bored and cares to explain this to someone who's recently gotten :curious as to how the kernel does stuff.) : :TIA, :-sno -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message