Hacker News new | past | comments | ask | show | jobs | submit login

> That doesn't really matter for discussing how correct code _should_ be written.

It absolutely does when you're talking about the semantics of virtually every program on earth

> It's equivalent to "if you call malloc(), you should call free()" -- you shouldn't demand that functions you invoke will call free() on your pointer. Same for open files.

There are many cases where the one calling malloc cannot be the one calling free and must explicitly document to callers/callees who is responsible for memory deallocation. This is a good example of where no convention exists and it's contextual.

But open files aren't memory and one cannot rely on file descriptors being closed without errors in practice, so people don't, and you can't just repave decades of infrastructure for no benefit out of ideological purity.




> There are many cases where the one calling malloc cannot be the one calling free and must explicitly document

That's fine. Special cases, documented deviation from the default convention.

> one cannot rely on file descriptors being closed without errors in practice, so people don't

You mean "so people don't call close(), and the error gets swallowed" (like the article points out for `cat`)? How's that good? Why is improving that "no benefit"?

> you can't just repave decades of infrastructure

Of course you can.

There are also lots of projects that were written without checking the return value of malloc() and then crashing. People make PRs and those get fixed.

Similarly people can come to the conclusion that LLVM and cat should call close() to not swallow errors, and then it will be done.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: