[comp.lang.c] Limit to array size under cc?

lamaster@pioneer.arpa (Hugh LaMaster) (11/30/87)

Is there a limit to the maximum size of an array using cc?  For
some reason, the maximum number that NR can be on a Sun (3.2) is
128766.  On a VAX (Ultrix 2.0) it is 130222.  Am I doing something
wrong or is it the compiler?
******************************************
Script started on Mon Nov 30 16:36:33 1987
csh[1] more junk2.c
#include <stdio.h>
#define NR 128767
[m
main()
{
    int nr ;
    int red[NR];
[m
    nr = NR;
[m
    for ( nr = 0; nr < NR; nr++ )
    {
            red[nr] = nr ;
[m
    }
    
    printf("\n red[%d] = %d\n", NR-1,red[NR-1] );
 }
csh[2] cc junk2.c
csh[3] a.out
Segmentation fault (core dumped)
script done on Mon Nov 30 16:40:12 1987



  Hugh LaMaster, m/s 233-9,  UUCP {topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov

(Disclaimer: "All opinions solely the author's responsibility")

chris@mimsy.UUCP (Chris Torek) (12/01/87)

In article <3537@ames.arpa> lamaster@pioneer.arpa (Hugh LaMaster) asks:
>Is there a limit to the maximum size of an array using cc?

and notes that the following program (my condensed version) crashes:

	#define NR 128767

	main() { int red[NR]; red[0] = 0; }

Time for the semi-annual stack size discussion again, I see....

Assuming that your compiler implements local arrays by using a
stack, there are several reasons for size limitations:

0) The compiler may use a register offset addressing mode with
   a fixed maximum offset.  Old Sun 68000 compilers, for instance,
   used a6@(offset), which limits the maximum offset to -32768,
   or 8192 four-byte integers.

1) There may be a total stack size limit imposed by the operating
   system and/or machine architecure.  `Large model' compilers for
   the 80x86 family tend to use a single stack segment, limiting
   one to 65536 bytes of stack.

2) [the one that bit you]  The 4BSD kernels (upon which the Ultrix
   kernels are based), like many other paging systems, want to be
   able to tell a `good' stack reference fault, where a program is
   growing its stack in a properly controlled manner, from a `bad'
   fault, where the program has managed to put junk into its stack
   pointer, or something equally incorrect.  To this end it has
   a `stacksize' resource limit.  In 4.3BSD, the default value for
   this limit is 512 kB.  The program above uses very nearly 512k
   for the array `red' alone; the space required for the rest of
   the program makes running that program exceed this.

   Solution: use the C-shell built in `limit' command, e.g.,
   `limit stacksize 1m' (yes, megabytes should be M, but csh
   refuses to believe in millibytes :-) so you may use lowercase).
   The built-in `unlimit' command raises a limit to its maximum
   value.  Alternatively, the program itself can set its stacksize
   limit.  For details, see man 1 csh and man 2 setrlimit.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris

gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/01/87)

In article <9583@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>   Solution: use the C-shell built in `limit' command, ...

A better solution would be to change the code so as not to allocate so
much on the auto stack.  There are many machines with much smaller
stack size limits, and code that assumes an "infinite" stack will not
port to such machines.  Huge amounts of space are best obtained via
malloc().

carroll@snail.UUCP (12/01/87)

	Sounds to me like it's not a problem in the compiler, but that there
is a finite amount of space in your stack segment. And when you try to allocate
1/2 M of stack, the OS "just says no".

daveb@laidbak.UUCP (Dave Burton) (12/02/87)

In article <9583@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
>In article <3537@ames.arpa> lamaster@pioneer.arpa (Hugh LaMaster) asks:
>>Is there a limit to the maximum size of an array using cc?
>and notes that the following program (my condensed version) crashes:
>	#define NR 128767
>	main() { int red[NR]; red[0] = 0; }
>   Solution: use the C-shell built in `limit' command, e.g.,
>   `limit stacksize 1m' (yes, megabytes should be M, but csh
>   refuses to believe in millibytes :-) so you may use lowercase).
>   The built-in `unlimit' command raises a limit to its maximum
>   value.  Alternatively, the program itself can set its stacksize
>   limit.  For details, see man 1 csh and man 2 setrlimit.

Or better yet, use some variant of MALLOC(3), maybe:
#include <stdio.h>
#define	NR	128768	/* or other suitably large value */
main()
{
	int *red;
	if ((red = (int*)malloc(NR)) == NULL) {
		fprintf(stderr, "cannot alloc %ld bytes\n", NR);
		exit(1);
	}
	red[0] = 0;
	/* etc. */
	exit(0);
}

Changing the shell limit will allow that invocation to work,
but future invocations will fail the same as the original.
Fix your program, don't fix BSD.
-- 
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540

rushfort@esunix.UUCP (Kevin Rushforth) (01/21/88)

in article <3537@ames.arpa>, lamaster@pioneer.arpa (Hugh LaMaster) says:
> Is there a limit to the maximum size of an array using cc?  For
> some reason, the maximum number that NR can be on a Sun (3.2) is
> 128766.  On a VAX (Ultrix 2.0) it is 130222.  Am I doing something
> wrong or is it the compiler?

[relevant part of example follows]

> #define NR 128767
> main()
> {
>     int red[NR];
>  }

This is not a limit on the size of an array imposed by your compiler,
but rather a limit on the stack size imposed by your OS.  4.2/4.3 based
Unix systems (as well as others) have compiled in limits on stack size
(the csh command "limit" will tell you how much).  To avoid the
problem, declare your array statically or malloc() space for it:

main()
{
    static int red[NR];
}

    -or-

main()
{
    int *red;

    red = (int *) malloc(NR * sizeof(int));
}
-- 
                Kevin C. Rushforth
                Evans & Sutherland Computer Corporation

UUCP Address:   {ihnp4,ucbvax,decvax,allegra}!decwrl!esunix!rushfort
Alternate:      {bellcore,cbosgd,ulysses}!utah-cs!esunix!rushfort

ok@quintus.UUCP (Richard A. O'Keefe) (01/24/88)

In article <594X@esunix.UUCP>, rushfort@esunix.UUCP (Kevin Rushforth) writes:
> This is not a limit on the size of an array imposed by your compiler,
> but rather a limit on the stack size imposed by your OS.  4.2/4.3 based
> Unix systems (as well as others) have compiled in limits on stack size
> (the csh command "limit" will tell you how much).

The limit is not compiled-in.  (There may be a compiled-in limit, but
the number Csh will tell you is usually well below it.)  For example,
	% limit stacksize
on my machine just now reported
	stacksize       512 kbytes
I then said
	% limit stacksize 2M
and it raised the limit to 2 megabytes.  This isn't really a good idea.
4BSD systems also have a rather nice function
	alloca(size)
allocates that much space in the stack; it will go away when the
calling function returns.  The stack size limit applies to alloca()
as well as to explicitly declared arrays.

gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/25/88)

In article <570@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <594X@esunix.UUCP>, rushfort@esunix.UUCP (Kevin Rushforth) writes:
>The [stack] limit is not compiled-in.

On some implementations (even of 4.nBSD), it is.  For example,
Gould UTX-32.

>4BSD systems also have a rather nice function
>	alloca(size)
>allocates that much space in the stack; it will go away when the
>calling function returns.

alloca() predates BSD.  Its use was stamped out in real UNIX,
because not all implementations could support a reasonable
alloca().  Inspired by discussions with J Q Johnson and others,
I came up with a "mostly portable" implementation of alloca()
that I posted a couple of years ago.  It doesn't work on some
IBMs and other inhospitable implementations, though.  Contact
me if you need a copy.
	- Gwyn@BRL.MIL