Question on large arrays in C

levy at ttrdc.UUCP levy at ttrdc.UUCP
Tue Feb 17 11:42:08 AEST 1987


In article <4124 at utcsri.UUCP>, flaps at utcsri.UUCP writes:
>>#define N 20480
>>main()
>>{
>>	double x[N];
>>	double y_1[N];
>>	double y_2[N];
>>	double y_3[N];
>>	double y_4[N];
>>	char *l = "";
>>When I run it, I get "Segmentation violation".
>>dbx reports the violation to occur on the "char *l" line.
>
>A more appropriate way to do this which continues to keep the scope of those
>variables restricted to the main() function is to declare them as static,
>in the same place as they are declared above, like:
>	static double x[N];
>, but this has radically different semantics in the case of a recursive
>function call - namely, that the different function invocations will share
>these variables rather than having private versions.  Hopefully your program
>doesn't require this feature of auto variables, in which case inserting
>'static' should solve your problem.
>Alan J Rosenthal

This will also result in an elephantine (HUGE) executable file on many
systems (if the compile gets that far, and doesn't run out of temp-file
ulimit or space first).  An extern (explicit, or implicitly so by being
declared outside of a function) does not have this problem (it will go
in bss) though it will no longer be hidden.

What WOULD be nice would be a way to do in C something analogous to the way
UNIX f77 treats the variable "d" in:

	program krunch
	double precision d (1 000 000)
c
c	dummy code so the array d does not get optimized out
c
	d(0)=d(0)+1.0
	end

Compiling this will result in an image with "d" in the .bss segment
(small executable file), yet the storage for "d" is not visible to other
modules which might be in the program.  A "static" declaration in C,
either inside or outside of a function, I have found to result in each
and every byte being initialized data.  Ugh.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|            dan levy            |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
                                        allegra,ulysses,vax135}!ttrdc!levy



More information about the Comp.lang.c mailing list