>He didn'tif (!(ptr = malloc(sizeof *ptr))) { // Fail}
if (!(ptr = malloc(sizeof *ptr))) { // Fail}
>>107069401I figure that if malloc() fails I have nothing more useful to do anyway than crash on a null dereference, so I don't bother checking for it. The OS will do what I was going to do anyway, blow up with an error message and terminate the process
>>107069410>error message"Segmentation Fault" is an error message, I guess.
>>107069410depending on your application and how you've designed it, yes, this is reasonable. unfortunately, people opt for this design even when they can react to a failed malloc. although, this is partially encouraged by the fact that on some systems, like linux, malloc will almost never fail.
Daily cnile struggles
>>107069449>unfortunately, people opt for this design even when they can react to a failed mallocWhat are some situations where you can sensibly continue when you can't allocate memory?
>>107069449if youre working on a consumer device and OS, malloc will never fail. if youre on embedded you shouldnt even be mallocing anyways. checking the return of malloc is just adding useless noise to your code.
>>107069501depending on your allocation and caching strategies you in theory can choose to free memory to make room for your allocation. for example, if you keep 1G of caches, you could opt to kill part or all of your cache in order to continue with your operation or to ensure that you can shut down safely. alternatively, you can merely choose to wait, like if it's a server that takes many concurrent requests.>>107069512you're right.
I don't like to allocate and check it with if on the same line. Does that make me a jeet?
>>107069401Malloc return value checking only actually works on Windows. On Linux, malloc will succeed but then the memory won't actually be allocated and then your app will crash.Linux has such a great design!
>>107069401malloc spam it bad ideamalloc worth using for 4k at minimum
you should have your own malloc that immediately crashes on null pointer if you're not going to handle OOM.>>107069410You don't want it to be a latent crash. e.g mallocing for some field in a struct and then crashing on nullptr a while after when you try to access the field.
over provisioning was a mistake
>>107070359it doesn't. unless you're doing something extremely retarded, it boils down to taste. the compiler makes it all the same anyway.
>>107069410well it gives you a way to gracefully failbut i guess it depends on what you do
>>107069401Sir, malloc never fail under GNU/Linux libc, sir. Actually the memory is not allocated until you try to access it, sir. Yes, sir, it's a flawed design and we should blame the retards at the C committee for it.
>>107069410it's not very respectful to bother your OS like that
>>107070617?
>>107071915If you have to change settings to get something to happen, that means you can't assume it's going to happen on all systems. This is the problem with Linux. Too many system configurations means that bugs will randomly appear for no reason and you can't debug it. On Windows this issue is greatly reduced. If it werks on my machine, it probably werks on your machine too.
If only you could make a wrapper for this.
>>107070640>You don't want it to be a latent crashmalloc can return non-null, and your program will still crash when you dereference. malloc does not allocate memory, it reserves it, and can reserve more that what's available
>>107072304>we who is we
>>107072304based
>>107069448what do you think the >core dumpedpart does
>>107073558litter your hdd with gigabytes of state
>>107071795If that's Linux behavior, why blame a C committee?
>>107073675stop being poor
>>107073705The model of individual allocations is considered harmful.
>>107069512Malloc may fail due to exceeding vm.max_map_count or a ulimit. There are still some distros that set vm.max_map_count really low, too.
>>107071993>man setrlimit
man setrlimit
>>107073487That's from the busybox source code.
>>107069501You might have a greedy algorithm that doesn't need as much as it's requesting, and you can simply request progressively less until either you get a successful return or you find you can't get what you want at all, at which point you can fail with an appropriate error message.
>>107073323i program for non-braindead operating systems like windows. the kernel lying to me about memory being available is not a concern I have.
>>107074335No, I'm not reading your man pages. stupid lintroon. where's the dialog box to change this setting. how do i use control panel to change it? i can't? lmao @ lintrtoons
>>107076624Then you're not a programmer and don't need to know about it, retard.
>>107076637you still haven't explained why I need to change settings to make malloc behave in a normal way?why is it acceptable for malloc on linux to return an address that's not actually allocated, so that when I go to use that address the app just crashes? isn't malloc supposed to return null if it couldn't allocate memory? seems like Linux is not following the standards.
>>107076648With strict allocation you need to overprovision swap or you can't use all you RAM. If you disable swap on Windows you get OOM even with half your memory unused.
>>107076648If you actually want to know, the reason is overcommitting of virtual memory, which itself is basically forced by using fork/exec to start new processes. You can disable overcommit and then malloc returns NULL like it should, but then fork() calls can fail due to not having enough free memory for a clone of the process, even though it would've been fine with overcommit enabled since the memory is shared between the process and its clone.Btw, most Linux boxes are like Windows and use swap instead of invoking the OOM killer.
>>107070617>>107071993Here's a better example.
>>107076773>atoi>ascii to integereven your second one should overflow, no?
>>107076803damn, quite the stupid mistake, but changing it to atoll still produces the same output, Linux malloc does return NULL on OOM
>>107076852>but changing it to atoll still produces the same output, i guess thats implementation defined then.>Linux malloc does return NULL on OOMi vaguely remember theres nuance to thatiirc theres actually a cap to when loonis decides your ask is unrealistic, and returns null on malloc, with standard settingsi just tried to allocate the double of my actual ram, and got a valid pointer
>>107069401>look how small my software isI don't think ladies will be very impressed with your small software.
>>107076852>>107076917no, waiti forgot i upgraded my ramyou cannot overallocate the double. NULL.but i got what looks like a valid pointer when i allocated 33gigs on my 32gig machine
>>107076198Windows just has the opposite problem: allocations fail if when there is memory available.
>>107071993You can also get ENOMEM if you run into VMA limit on the kernel (basically if you have high memory fragmentation).
>>107077333I've never actually had this happen on my Windows machine. Even when something has a memory leak or I try to load some neural network that's too big, all that happens is that the app slows down and the computer gets a bit laggy, and then I can just kill it in task manager and continue. In Linux everything would crash due to the OOM killer and/or the system would become totally unusable due to excessive paging.I used to have gentoo on my laptop and when compiling chromium it would run out of memory and freeze EVERYTHING to the point where the only option is to use a Sysrq key to kill everything and start over. That's why I don't use linux anymore. Shit OS with bad 1960s design.
