Phili Colavito, Mob Accountant (mcsweeneys.net):
I tell Frankie the Eagle I'm going to Staples to pick up the new version of QuickBooks. He says send one of the boys to get it ....
My reasoning at this point goes that, if your allocations are failing then the system is already in a pretty fragile state. If there's not enough free memory to give you 2k, the whole system will probably become unusable soon anyhow. But are there any more codified ideas on this subject?
Cuban - how does VM work in the xbox? Do you have to be careful about filling up memory, like does anything catastrophic happen to the system? Or does the xbox have a disk-swapfile-backed VM system so performance just drops off after a point?
Posted by Ethan at February 10, 2004 10:59 AMI always check, even in functions that return void. Sure, the program's going to go south anyhow, but I would rather it not be through my dereferencing a null pointer. Now, I usually attempt to log an error message too, but since memory allocation is failing, how likely is it that fprintf() is going to succeed? :-)
Posted by: Nik on February 10, 2004 11:21 AMI agree with Nik in theory, but checking a lot makes your code like five times as long, which pisses me off. I'll do it anyway, but I don't have to be happy about it.
I can also vouch that Nik really does check all the time :P
Posted by: daisie on February 10, 2004 01:50 PMI don't usually check in user-level code. It's very unlikely to happen, the system's going to unresponsive / unstable at that point, and there's nothing I could do about it anyway. And Objective C lets you send messages to nil.
But if I were writing kernel code, I would. Then the issue is reliability vs performance.
Posted by: John R Chang on February 10, 2004 02:00 PMits a requirement. in-kernel you should be dynamically allocating as little memory as possible after init, but where its necessary you have to check it.
Posted by: john on February 11, 2004 12:34 AMok, I'm no software engineer, but I hack bullshit together from time to time. And this is seriously more of a question than a suggestion:
how unreasonable is it to write some sort of malloc wrapper-function that does the checking, the allocation, and the error logging/reporting all for you...
In one sense it makes the code more readable (to daisie's point) and easier to write; in the other sense, people now have to know what your ethanMalloc() function does.
In an environment like mine, where everything is (to my understanding) EXTREMELY TIGHT requirement driven (i.e. For every requirement in the spec, show me which function/LOCs perform it; For every function/LOC, show me which requirement you are implementing) doing something like this may be a little harder, but I'm not sure how things work in the land where you sit at your desk with a beer looking at the $1000 monitor you bought with your own money.
Posted by: adam on February 11, 2004 01:35 PMEvery time I allocate memory, I both assert that the result is non-nil and test the result before using it. Granted, I write embedded software and every allocation I do can (and likely has) failed, but I'm with Adam: it's not that hard.
The other point I have is as pertains code reuse. I like using code that's already been tested, but I can't use code in my environment if it isn't paranoid about checking for resource constraints. Likewise, if my code is paranoid about such stuff, it's likely to be more efficient/reliable and thus less of a risk for someone else to use, whether their environment allows them to get away with ignoring failures or not.
Posted by: ned on February 11, 2004 03:08 PMHa ha! Sorry my code is five times as long, Daisie. Feel free to rip out all those checks for malloc failures. :-)