> it filter_maps them away, which, to be fair, is what I'd do too
Ok, I don't know much rust and I imagined filter_maps reported to the main app. If it is shallowing them, then to me it is a big + for C++ in that area. It seems I will have to agree to disagree here, but shallowing the error is not what I would do at all. This program has the possibility to give you a completely wrong result, and you would never know. You could use that result in other thing, say publish a study where you claim there were only 100 words in the files you processed but there were 1000 because your program crashed and didn't warn you.
> If you care about security, you abort a C program when allocation fails.
Well, that's why I personally prefer C++ and exceptions. They abort by default, let you handle if you want/can.
But I think my original point was lost. My complain was that this code wasn't checking at all for failure. Shouldn't it be something like:
if(!w->next)
w->next = calloc(1, sizeof(*w));
if (!w->next)
abort();
w = w->next;
I mean, in this particular case it will indeed blow up because when it goes back to the while(w->word) w will be null and you will reference a null pointer. But that's mostly luck, and might be not be true anymore if you make changes to the code in the future. If you care about security, you should check all allocs, and abort if null. And that's my beef with C: It shallows and continues instead of crashing or reporting when there is an error.
> but if the task is "count words in files", you're nuts if you do anything but blow up when malloc fails.
I won't disagree here, if the task is count words in files. I was just trying to explain why imo, not all "sane" programs should abort in failed malloc.
Ok, I don't know much rust and I imagined filter_maps reported to the main app. If it is shallowing them, then to me it is a big + for C++ in that area. It seems I will have to agree to disagree here, but shallowing the error is not what I would do at all. This program has the possibility to give you a completely wrong result, and you would never know. You could use that result in other thing, say publish a study where you claim there were only 100 words in the files you processed but there were 1000 because your program crashed and didn't warn you.
> If you care about security, you abort a C program when allocation fails.
Well, that's why I personally prefer C++ and exceptions. They abort by default, let you handle if you want/can.
But I think my original point was lost. My complain was that this code wasn't checking at all for failure. Shouldn't it be something like:
if(!w->next) w->next = calloc(1, sizeof(*w));
if (!w->next) abort();
I mean, in this particular case it will indeed blow up because when it goes back to the while(w->word) w will be null and you will reference a null pointer. But that's mostly luck, and might be not be true anymore if you make changes to the code in the future. If you care about security, you should check all allocs, and abort if null. And that's my beef with C: It shallows and continues instead of crashing or reporting when there is an error.> but if the task is "count words in files", you're nuts if you do anything but blow up when malloc fails.
I won't disagree here, if the task is count words in files. I was just trying to explain why imo, not all "sane" programs should abort in failed malloc.