Thread: Changing default stack size with MinGW/GCC?

Why do you need to do this? Maybe there is a better alternative.

Originally Posted by laserlight

Why do you need to do this? Maybe there is a better alternative.

Why do I need to screw around using malloc (and free) on an array of structs that's ALWAYS the same size just because it's a little big? With everyone running systems with gigabytes of RAM, why is the stack still defaulted to like 8MB? That's what I want to know. Why add extra coding just to save on a little memory? My thinking has always been that malloc should only be necessary for handling things of dynamic size. Like allocating an array to load some random file that could be any size.

Originally Posted by Viper187

Why do I need to screw around using malloc (and free) on an array of structs that's ALWAYS the same size just because it's a little big? With everyone running systems with gigabytes of RAM, why is the stack still defaulted to like 8MB? That's what I want to know. Why add extra coding just to save on a little memory? My thinking has always been that malloc should only be necessary for handling things of dynamic size. Like allocating an array to load some random file that could be any size.

Well, the fact that you think that doesn't make it so.

The purpose of the stack is to hold function invocation frames -- function parameters, return addresses, and local variables. It doesn't magically turn into something else just because you wish it.

Back to your problem, if this thing is really fixed size and doesn't change, you could declare it as "static" which will put it in static memory instead of on the stack.

Originally Posted by Salem

Because whatever <insert large number here> you think you've figured out, it's almost certain that at some future point in time it won't be big enough and you're back to editing the code (and fixing things).

> My thinking has always been that malloc should only be necessary for handling things of dynamic size. Like allocating an array to load some random file that could be any size.
So your approach is to allocate several MB of "just in case", where 99% of the time very little of it will actually be used (small files), and the only time it will fail is when you try and process a file which won't fit in your statically sized buffer. That truly is a waste of resources.

Not really, in this case. When I declare this array I use a defined constant for the size so anything else I use that relies on what size that array is all changes with changing one number in a header.

No, when I load a file, I open it and find out the size, THEN malloc an array to hold it. That's what I mean by only using malloc for dynamic stuff. Arrays that I KNOW I want one size and things are coded to utilize that should not need malloc.

Originally Posted by brewbuck

Well, the fact that you think that doesn't make it so.

The purpose of the stack is to hold function invocation frames -- function parameters, return addresses, and local variables. It doesn't magically turn into something else just because you wish it.

Back to your problem, if this thing is really fixed size and doesn't change, you could declare it as "static" which will put it in static memory instead of on the stack.

I never looked into how static variables differed from regular, but that's looking like a good choice.

Here's an example of what I'm working with.... This is from a program I wrote a few years ago, Called Renegade. It's probably around 20 source files total. I'm in the process of reworking it a lot. It's a large program divided into tabs with a dialog loaded and slapped on each tab. Hey, it worked. The purpose of the program is to make cheat codes (Gameshark, etc) for console games that can be run in an emulator, since many emulators have limited or non-existent built in cheat functions. The last release version with source is here. Like I said, it's a ton of source...

Code:

//rex.h
#define MAX_PRESETS 20
#define MAX_MAP_BLOCK_NAME 15
#define MAX_MAP_BLOCKS 1000
#define SEARCH_LABEL_MAX 100

typedef struct _SYS_VARS {
	u32 ProcPoint[MAX_MAP_BLOCKS];
	u32 ProcAddr[MAX_MAP_BLOCKS];
	s32 ProcOffset[MAX_MAP_BLOCKS];
	u32 SysAddr[MAX_MAP_BLOCKS];
	u32 AreaSize[MAX_MAP_BLOCKS];
	int AreaCount;
	char AreaName[MAX_MAP_BLOCKS][MAX_MAP_BLOCK_NAME];
} SYS_VARS;

//Hook vars
typedef struct _HOOK_VARS {
    char Name[1024];
    char HookType;
    char ProgramPath[MAX_PATH];
    char ProcName[MAX_PATH];
    int Endian;
    u32 SystemId;
    PROCESS_INFORMATION HookedProcess;
    SYS_VARS Sys;
} HOOK_VARS;

Code:

//main.c
SYS_VARS SysVars[NUM_SYSTEMS];
extern HOOK_VARS Presets[MAX_PRESETS];

BOOL CALLBACK MainProc(HWND hwnd, UINT Message, WPARAM wParam, LPARAM lParam)
{
/......./
case WM_INITDIALOG:
{
InitSysVars();
}

Code:

//tab_hook.c
HOOK_VARS Presets[MAX_PRESETS];

//there's a bunch of possible handling in here for the dialog involving editing this array. It's either initialized with default values OR read in from a config file.

Code:

//lib_rex.c
int InitSysVars()
{
	memset(SysVars, 0, sizeof(SYS_VARS)*NUM_SYSTEMS);
	/***N64***/
	SysVars[SYSTEM_N64].AreaCount = 2;
	strcpy(SysVars[SYSTEM_N64].AreaName[0], "Lo-Res RAM\0");
	SysVars[SYSTEM_N64].SysAddr[0] = 0x80000000;
	SysVars[SYSTEM_N64].AreaSize[0] = 0x400000;
	strcpy(SysVars[SYSTEM_N64].AreaName[1], "Hi-Res RAM\0");
	SysVars[SYSTEM_N64].SysAddr[1] = 0x80400000;
	SysVars[SYSTEM_N64].AreaSize[1] = 0x400000;
	/***NDS***/
	SysVars[SYSTEM_NDS].AreaCount = 1;
	strcpy(SysVars[SYSTEM_NDS].AreaName[0], "RAM\0");
	SysVars[SYSTEM_NDS].SysAddr[0] = 0x02000000;
	SysVars[SYSTEM_NDS].AreaSize[0] = 0x400000;
	/***PS1***/
	SysVars[SYSTEM_PS1].AreaCount = 1;
	strcpy(SysVars[SYSTEM_PS1].AreaName[0], "RAM\0");
	SysVars[SYSTEM_PS1].SysAddr[0] = 0x80000000;
	SysVars[SYSTEM_PS1].AreaSize[0] = 0x200000;
	//need to find scratchpad
	/***PS2***/
	SysVars[SYSTEM_PS2].AreaCount = 1;
	strcpy(SysVars[SYSTEM_PS2].AreaName[0], "EE\0");
	SysVars[SYSTEM_PS2].SysAddr[0] = 0x00100000;
	SysVars[SYSTEM_PS2].AreaSize[0] = 0x1F00000;
	/***GB..........*/
	SysVars[SYSTEM_GBA].AreaCount = 2;
	strcpy(SysVars[SYSTEM_GBA].AreaName[0], "WRAM\0");
	SysVars[SYSTEM_GBA].SysAddr[0] = 0x02000000;
	SysVars[SYSTEM_GBA].AreaSize[0] = 0x40000;
	strcpy(SysVars[SYSTEM_GBA].AreaName[1], "IRAM\0");
	SysVars[SYSTEM_GBA].SysAddr[1] = 0x03000000;
	SysVars[SYSTEM_GBA].AreaSize[1] = 0x8000;
	return 0;
}

Originally Posted by Viper187

Why do I need to screw around using malloc (and free) on an array of structs that's ALWAYS the same size just because it's a little big? With everyone running systems with gigabytes of RAM, why is the stack still defaulted to like 8MB? That's what I want to know. Why add extra coding just to save on a little memory? My thinking has always been that malloc should only be necessary for handling things of dynamic size. Like allocating an array to load some random file that could be any size.

Simply because that's not what the stack is for.

It's like saying "why don't we make all vehicles the size of a bus and capable of transporting at least 30 people". It's because that's not what a car is for.

Because whatever <insert large number here> you think you've figured out, it's almost certain that at some future point in time it won't be big enough and you're back to editing the code (and fixing things).

If you're just worried about say

Code:

int main ( ) {
    int array[1000000];
}

Then the quick and simple fix is to just do

Code:

int main ( ) {
    static int array[1000000];
}

and hey presto, no more stack space issues.

> My thinking has always been that malloc should only be necessary for handling things of dynamic size. Like allocating an array to load some random file that could be any size.
So your approach is to allocate several MB of "just in case", where 99% of the time very little of it will actually be used (small files), and the only time it will fail is when you try and process a file which won't fit in your statically sized buffer. That truly is a waste of resources.

Originally Posted by Viper187

I guess declaring a static in a header doesn't make it global. You can't extern a static, can you?

The normal purpose of declaring a static variable at file scope is to make it restricted to the particular translation unit, hence it would not make sense to also declare it extern since that means that you want it to be global across translation units. On the other hand, you don't have to declare it static at file scope for it to have static storage duration and hence be likely to be stored similiarly to variables declared static.

Have you tried defining it at file scope in a single source file, then declaring it extern in a header? The static keyword was suggested in the context of a local variable, and indeed declaring a local variable to be static would give it static storage duration. However, if it is already at file scope (as an intended global variable would be), then it also has static storage duration. Declaring it static in such a case just ensures that it is "private" to the translation unit.

Originally Posted by Viper187

That's what I've been doing, and I broke the stack with it.

That's weird since the global array shouldn't be on the stack, although I believe that this is technically implementation detail.

I suggest that you post the smallest and simplest compilable program that demonstrates this problem (though of course we may have to modify the array size as needed if we want to try it). My guess is that somewhere, you have another array or something that is local.

Also, what is the version of the MinGW port of gcc that you are using?