From seggers@semyam.dinoco.de  Fri Aug  7 13:22:30 1998
Received: from tim.xenologics.com (tim.xenologics.com [194.77.5.24])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA13502
          for <FreeBSD-gnats-submit@freebsd.org>; Fri, 7 Aug 1998 13:22:22 -0700 (PDT)
          (envelope-from seggers@semyam.dinoco.de)
Received: (from uucp@localhost)
	by tim.xenologics.com (8.8.5/8.8.8) with UUCP id WAA06250
	for FreeBSD-gnats-submit@freebsd.org; Fri, 7 Aug 1998 22:21:14 +0200 (MET DST)
Received: (from seggers@localhost)
	by semyam.dinoco.de (8.8.8/8.8.8) id WAA17745;
	Fri, 7 Aug 1998 22:19:35 +0200 (CEST)
	(envelope-from seggers)
Message-Id: <199808072019.WAA17745@semyam.dinoco.de>
Date: Fri, 7 Aug 1998 22:19:35 +0200 (CEST)
From: Stefan Eggers <seggers@semyam.dinoco.de>
Reply-To: seggers@semyam.dinoco.de
To: FreeBSD-gnats-submit@freebsd.org
Cc: seggers@semyam.dinoco.de
Subject: clearly marking gcc extension in swap_pager.c
X-Send-Pr-Version: 3.2

>Number:         7523
>Category:       kern
>Synopsis:       clearly marking gcc extension in swap_pager.c
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Aug  7 13:30:00 PDT 1998
>Closed-Date:    Mon Aug 10 00:29:25 PDT 1998
>Last-Modified:  Mon Aug 10 00:30:13 PDT 1998
>Originator:     Stefan Eggers
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
none
>Environment:

	-current sources from Wednesday.

>Description:

	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.

>How-To-Repeat:

	Read swap_pager.c and look for these non-ANSI constructs.

>Fix:
	
	I don't have an alternative implementation to offer.  Just an
error message which I hope helps in case someone tries it with another
compiler.

	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
have to read a bit about dynamic memory in the FreeBSD kernel first as
I am not 100% sure if it is legal to use in this place.  I don't think
I can do that in a few minutes.  ;-)

--- swap_pager.c.ORIG	Tue Jul 28 19:58:31 1998
+++ swap_pager.c	Fri Aug  7 22:02:01 1998
@@ -933,13 +933,25 @@
 	int count, reqpage;
 {
 	register struct buf *bp;
+#ifdef __GNUC__
 	sw_blk_t swb[count];
+#else
+#error XXX uses GCC extension of computed array size
+#endif
 	register int s;
 	int i;
 	boolean_t rv;
+#ifdef __GNUC__
 	vm_offset_t kva, off[count];
+#else
+#error XXX uses GCC extension of computed array size
+#endif
 	vm_pindex_t paging_offset;
+#ifdef __GNUC__
 	int reqaddr[count];
+#else
+#error XXX uses GCC extension of computed array size
+#endif
 	int sequential;
 
 	int first, last;
@@ -1159,14 +1171,22 @@
 	int *rtvals;
 {
 	register struct buf *bp;
+#ifdef __GNUC__
 	sw_blk_t swb[count];
+#else
+#error XXX uses GCC extension of computed array size
+#endif
 	register int s;
 	int i, j, ix, firstidx, lastidx;
 	boolean_t rv;
 	vm_offset_t kva, off, fidx;
 	swp_clean_t spc;
 	vm_pindex_t paging_pindex;
+#ifdef __GNUC__
 	int reqaddr[count];
+#else
+#error XXX uses GCC extension of computed array size
+#endif
 	int failed;
 
 	if (vm_swap_size)
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
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
State-Changed-From-To: open->closed 
State-Changed-By: phk 
State-Changed-When: Mon Aug 10 00:29:25 PDT 1998 
State-Changed-Why:  
we really need a "State: filibustered", but I think "closed" will do. 
>Unformatted:
