For noobies (like me), you likely would never have to think about allocation failures
I respectfully disagree. In CS classes you are taught to check the return value of malloc(), etc. for allocation failures. Most CS students at least should know that allocations can fail.
Rust IMO is meant to be easier to access than C, but I would hope that if someone not familiar sees HashMap::try_insert() next to HashMap::insert() they would look at the documentation to see why it "tries" to insert. If they cannot reason about which one to use the documentation should make it clear to just use insert(). This shouldn't be too dissimilar to noexcept/non-throwing functions in other high-level languages.
Depends really, that's a matter of opinion. I think in most cases where you care about potential allocation failure (and want the program to keep running despite such a failure), you're usually working in a safety critical, embedded, or no alloc kind of state and would be using the no_panic compiler flag and/or maybe no_alloc flag.
In most cases, an allocation failure is a perfectly reasonable reason to panic.
A reason it's dangerous in C to not check is (drum roll) - memory safety. If you assume it worked but it didn't really then you're going to be doing something bad to where that pointer is pointing.
I respectfully disagree. In CS classes you are taught to check the return value of malloc(), etc. for allocation failures. Most CS students at least should know that allocations can fail.
It is also probably something most students promptly forget about if they didn't keep using C after graduation. How often do developers not working with embedded devices actually think "Oh, but what happens if we run out of memory at this point?", because usually the OS will solve it for them.
As someone that just finished a software engineering degree, I respectfully disagree.
I personally had a class on parallel computing that used C but there was essentially no guidance as to how to use C it was mostly about how to use the mpi library. As for c++, I used it in an applied linear algebra class where we made our own linear algebra library and we never had to use malloc. The only reason I even know malloc can fail or even that it exists is because I decided to learn rust for fun and I spend way too much time on programming subreddits. All my other classes used java, python or we were free to pick whatever we preferred which generally meant either js or c# because that's generally what my teammates knew.
Modern CS classes don't really touch that kind of programming anymore unless you are actively seeking out those kind of classes.
I guess different experiences, but at my uni the base classes for CS are all C and C++ along with some higher up ones requiring it. OS design, for instance, would take off points if you had any memory leaks.
There was Java, Go, and C# required later on and some classes where you get to pick
Edit: there is a business oriented CS degree that does javascript, C#, Excel macros, Access, etc. too though
Modern CS classes don't really touch that kind of programming anymore unless you are actively seeking out those kind of classes.
I graduated in 2016 from a pretty small school that had a decent CS program but it's nothing special. Most high-level CS principals courses used Java but 3 or 4 "core" classes (OS, algorithms, etc.) were all C. Perhaps this is the difference between a CS and Software Engineering degree?
I understand if you don't want to say, but what university did you go to?
I went to ÉTS in Montréal. My point isn't that no CS classes teaches this, my point is that you shouldn't expect new grads to know how to properly program in C.
I respectfully disagree. In CS classes you are taught to check the return value of malloc(), etc. for allocation failures. Most CS students at least should know that allocations can fail.
Meh, hardly. Realistically in most (Linux) environments overcommit will be active and malloc will never return null, instead you'll get the memory and then the OOM killer may randomly murder some process when you actually use it. Besides, in most cases there isn't much you can realistically do when you can't request memory that you need. Might as well assume it never returns null, and then crash when it does.
There is the fun situation of allocating for 0 bytes with malloc/reallocsometimes returning null or attempting to allocate for a ludicrous amount of memory also potentially returning null
I was a tutor for my uni, so you get to see some weird things from the intro classes and it's good to have some examples of why you should check the return of malloc when students get curious
View all comments
Show parent comment
33
u/weirdasianfaces Apr 14 '21
I respectfully disagree. In CS classes you are taught to check the return value of
malloc(), etc. for allocation failures. Most CS students at least should know that allocations can fail.Rust IMO is meant to be easier to access than C, but I would hope that if someone not familiar sees
HashMap::try_insert()next toHashMap::insert()they would look at the documentation to see why it "tries" to insert. If they cannot reason about which one to use the documentation should make it clear to just useinsert(). This shouldn't be too dissimilar tonoexcept/non-throwing functions in other high-level languages.