6 ms·
It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never che
by alacombe 9y ago
It is not surprising that C gets that much of a bad reputation when devoloper show such poor capacity at managing errors; malloc(3) return values are never checked and everything is expected to always succeed, throughout the source tree.
- rvense 9y agoOn a modern Linux kernel in its default configuration this is AFAIK actually the case? The kernel overcommits memory. http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6 http://www.win.tue.nl/~aeb/linux/lk/lk-9.html#ss9.6
- bradfa 9y agoDo other *nix systems behave differently regarding overcommit of memory and malloc() really only erroring out when virtual memory is exhausted (which basically never happens)?
- megous 9y agoIt can happen, I had various issues with my VPS provider which set limits on virtual memory use in his virtualization solution. Programs would crash with malloc failures despite overcommit being enabled.
- megous 9y agoIt can still fail. Also it is not very bright to depend on some kernel configuration in order not to crash unpredictably. Also it's not portable. Some targets don't have MMU.
- pjmlp 9y agoThere are languages that don't allow the programmers to do such kind of failures.
- alacombe 9y agodon't focus on malloc(3), it's a problem of thinking the design of the code and the relevant backpressure if the state goes SNAFU.
- baybal2 9y agoCompetent C devs are rare these days. Just too many did retire. At the very start of my professional career I thought of becoming embedded dev, but I was disheartened by the job market. The very few jobs I found were like "Senior C dev, minimum 7 years subject matter experience, $65k" at the time when web dev roles were paying 85k+ and were so easy and dumb... What distinguishes a good C developer? A high self discipline. That language gives you a lot of ways to introduce bugs, but unlike JS you do have clear realisation why they appear most of the time.
- hackits 9y agoYou can use my own experience as a little bit of anecdotal evidence. I started out of collegue and started programming in C/C++ as a game dev. I started at 40K AUD in Sydney in 2002 just before the housing boom here in Australia. Granted stayed with the business for 4 years. During the time my colleges got a job in web development CRUD application systems for the web. Their starting salary was 85K. I remember walking into the CTO/CEO office at the time asking how much they valued experienced C/C++ developers. They honestly said at the time that (frank) who had 10+ years doing game dev they couldn't see any point in paying him anymore than 60K a year. I thanked them for their time and went back to my desk. Next day I walked in and handed in my resignation. Both the CEO/CTO was shocked. The next week I walked into a web development shop (oracle/java/javascript) and tripped my salary.
- sbov 9y agoGame dev is built on the backs of people sacrificing salary for "working in games". You really can't compare it to any other job. All my friends who worked with C/C++ in game dev that moved out of game dev, but still used C/C++, at least doubled their salary.
- hackits 9y agoA job is a job. For me the simple truth of the matter is I couldn't support the quality of life I wanted to live working in games and the salary and rewards they where offering. It was fun, but going back to C/C++ is something I would avoid at all costs, although if the salary doubled over night I would put up with C++ although I think I would take up drinking.
- raverbashing 9y agoThe reason for not checking malloc is that it's most likely to kill your program instead of returning a failed allocation
- icebraining 9y agoWhy would a system do that? Either it overcommits, in which case the malloc won't fail (programs get killed only when they try to actually use the memory) or it doesn't, in which case there's no reason to kill it.
- raverbashing 9y agohttps://www.memset.com/docs/additional-information/oom-killer/ https://www.memset.com/docs/additional-information/oom-kille...
- icebraining 9y agoYes, I know about the OOM killer, but it doesn't trigger when you malloc(), only when you actually try to use the memory. In fact, that's the point of the OOM killer: since many applications allocate more memory than they actually need, Linux lets them allocate more memory than what is in fact available, and only kills 'em off when the bluff fails.
- megous 9y agoThe program will crash on null pointer dereference most likely. Malloc will not abort. Some libraries (like glib2) wrap malloc so that it aborts on failure, but standard malloc will never crash.
- alacombe 9y agoin the kernel, it will kill your machine or create exploitable security holes. Check your malloc(3).
- ygra 9y agoWasn't in the case on Linux due to overcommit that allocations always succeed anyway? So a novice C developer, working on 64-bit Linux may assume that malloc calls never have to be checked.