From owner-freebsd-bugs Sat Aug 8 03:00:08 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA23917 for freebsd-bugs-outgoing; Sat, 8 Aug 1998 03:00:08 -0700 (PDT) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA23903 for ; Sat, 8 Aug 1998 03:00:03 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id DAA22471; Sat, 8 Aug 1998 03:00:01 -0700 (PDT) Date: Sat, 8 Aug 1998 03:00:01 -0700 (PDT) Message-Id: <199808081000.DAA22471@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.ORG From: Bruce Evans Subject: Re: kern/7523: clearly marking gcc extension in swap_pager.c Reply-To: Bruce Evans Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR kern/7523; it has been noted by GNATS. From: Bruce Evans To: FreeBSD-gnats-submit@FreeBSD.ORG, seggers@semyam.dinoco.de Cc: Subject: Re: kern/7523: clearly marking gcc extension in swap_pager.c Date: Sat, 8 Aug 1998 19:58:58 +1000 > In a thread in freebsd-hackers John Polstra said that when >using gcc extensions they should be #ifdef'ed and have an alternative >implementation. In swap_pager.c this is missing in two functions >where arrays with computed size (a gcc extension) are used. This extension is in the C9x draft, so we will probably be able to depend on it by the time we ifdef all gcc-only extensions. However, I think it shouldn't be used in the kernel, because the kernel stack is limited. Limits on auto array sizes must be known at compile time, since runtime checks would be wasteful and recovery from stack overflow would be too difficult. If the limits are known, they can just be used to allocate sufficiently large arrays. I looked at this a year or two ago. There seemed to be no actual problem with stack growth because all the array sizes were small (< 10 ints?). > The propper fix is of course to use dynamic memory for these >arrays but doing that is much work and error prone as in front of every >return statement one has to add a free for it. Besides this I first I think dynamic allocation would be too slow here. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message