I assumed that he knew this, but yeah, it's worth mentioning.
Every modern OS overcommits. You can ask for a terabyte of RAM straight up and get it. Except your process doesn't have ownership of it. The OS won't assign pages to your process until you actually write to a page.
This is good advice in general, but IIRC in practice it depends on the OS.
malloc only fails on Linux if it runs out of virtual memory space for your process, which can only really happen if you do something stupid. Windows has a quota system instead, so malloc can fail.Sort of. Windows will refuse to give you 1TB of RAM. It only doles out pages once they're called for, that's true, but this is just an optimization to keep the page-scrubbing thread happy. It doesn't actually overcommit - there's no OOM killer on Windows.
//DemetiCa.c
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
int main(){
//use a collatz sequence to generate dynamic memory
int stnum, count; //start num is the start of the collatz
int *holdCol = (int*)malloc(sizeof(int));
//int holdCol[1];
//initialize stnum
stnum = 45, count = 1;
*holdCol = stnum;
//basic collatz loop
//holdCol[0] = stnum;
//int *p_holdCol = holdCol;
while(stnum != 1){
if(stnum % 2 == 1)
stnum = (stnum*3)+1;
else
stnum /= 2;
//count++;
//now try to allocate the memory
holdCol = (int*)realloc(holdCol, (count +1) * sizeof(int));
if(holdCol == NULL){
//abort abort abort
printf("Memory allocation failure. Terminating program\n");
return 1;
}else{
//holdCol = tAr;
holdCol[count++] = stnum;
}
}//end while loop
//just to check if the dynamic array worked as intended
for(int i = 0; i < count; i++)
printf("%d\n", *(holdCol+i));
free(holdCol);
return 0; //always important
}
Yeah, the C spec leaves a fair bit of room for interpretation in a number of memory-related areas like this. As such, in practice a programmer should always cover his ass.
Not super uncommon if you are loading AI models—a problem that will only become more common. Then again, one could argue that falls under doing something stupid
Somebody already mentioned Windows, but OpenBSD doesn't overcommit either, and Linux can be easily configured not to overcommit via
sysctl vm.overcommit_memory=2. Properly handling OOM is hard, and a big reason is that C/POSIX's only mechanism to signal low memory conditions is malloc returning null, at which point you're probably so low on memory that there's indeed nothing you can do anymore - unless you've prepared for the necessary contortions in advance. Linux has some opt-in cgroups stuff to inform processes that system memory is about to get scarce, and I believe Windows has a similar mechanism, but I rarely see them used in practice.
Is it just me (and I'm not dogging on you specifically @Chiang Kai-shek, this is a very common style), but does anyone else absolutely hate this style of declaring int variables in C?
int*".int".int *foo, *bar;
I agree, I'm not a fan.
int and * together represent the type of hcol. When I read code with a strange coding style I'm not above cloning it, loading it into clion and auto-reformatting the whole damn thing so I can read it fluently.if (condition)
{
doSomething();
}
In addition to everyone else's good answers, I'll toss one in: the performance is unpredictable since you don't know exactly how long malloc is going to spend rummaging through its data structures to find you a memory block. Not that it matters for most (nearly all) applications since memory allocators are typically highly optimized and field-tested, and it usually doesn't add up to enough time to matter. But when it does matter, programmers will sometimes do "arena allocation" where they grab a big chunk of memory upfront and then parcel it out themselves one way or another.
Reminds me that if you're using Linux and especially if your hardware is limited (e.g. on an SBC) configure your system to use the almighty Alt+SysRq+F combination for when one or more processes hog memory and the system starts thrashing:
This is a pet peeve of mine too.
int* foo, bar; foo and bar are different typesi++ and ++i, and they behave slightly differently
I prefer to do it the way you hate, but it's sort of muscle memory at this point from stuff like kernel work. With the case of your caveat, it's arguable the way I prefer is less ambiguous due to the way C parses these definitions.
Lol go's formatter also insists on tabs which torches me up inside. I specifically distributed an in company pre-commit script to my coworkers that does all the gofmt stuff, except it also transmutes the tabs into spaces.
Use-and-then-increment is a common enough pattern that I could see wanting to call it out for the compiler in the days when compilers were less smart. All that stuff like
array[i++] = next_val;while (*i++ = *j++);while (whatever)
{
array[i] = next_val;
/* more lines */
i++;
}There's nothing to figure out, there's no optimization that it lets the compiler do.
array[i++] = next_val; and array[i] = next_val; i++; will both compile into something that looks likemov DWORD PTR [rbx+(4*rax)], rcx
inc rax
I think the point is just to avoid writing a separate statement to increment after. The last time you use it, you post-increment it.