4 ms·
> If you make the array extremely large, your program will still compile just fine. It may compile, but it might not link. With very large static arrays, in th
by smcameron 2y ago
> If you make the array extremely large, your program will still compile just fine.
It may compile, but it might not link. With very large static arrays, in the link step, you might get something like this:
my_program.o: In function `my_function':
my_program.c:(.text+0xf38): relocation truncated to fit: R_X86_64_PC32 against `.bss'
It's due to the linker assuming statically allocated things can be addressed with a 4-byte pointer (I encountered this on x86_64 arch). Using malloc to allocate the array will fix this.
That being said, using malloc once to allocate a very large array will get the same dynamic allocation of backing RAM as described in the article on linux, assuming overcommit is enabled.
- api 2y agoAFAIK just about all Unix-like OSes overcommit and dynamically allocate like this. I know macOS and xBSD (which which macOS is one) do this. I don't know what Windows does.
- simiones 2y agoI don't know about other Unixes, but Linux allows the sysadmin to decide if overcommit is allowed or not. I believe Windows does as well, but the default is to not overcommit.
- bakugo 2y ago> I don't know what Windows does. Windows does not allow overcommit. The commit limit is the total size of RAM + the size of the page file, attempting to commit more than that will fail.
- bregma 2y agoThat's where -fPIC (as opposed to -fpic) comes in.