Hacker News Reader

Comment by david_for_you | Hacker News Reader

This seems to be missing a return in the NULL check for handle in the match_file function. This leads to fgets being called with a NULL pointer, which I don't know what it does, it may be OK.

I would argue that this is why a "better C" can be useful, it's the kind of error that would be much harder to make in rust.

View on HN

There is missing NULL check, but it doesn't crash, because the function would get nonexistent filename only if filesystem driver would do something strange (or file would be deleted just between readdir and fopen). xD I also noticed, that I don't close files and directories. Not a big deal, because fully functional and 100% correct program wasn't the goal here. :)

EDIT: Actually fopen would return NULL when file is not readable. My bad. Anyway, such problems are trivial to debug.

I like that I don't have to spend the time debugging trivial problems like these in Rust though. The compiler catches them for me, and I get more time and brain power to spend debugging nontrivial problems. It adds up.

Everything is matter of price. Such an error is nobrainer actually, because just before I get an error message. If I don't know that yet, I run on gdb and everything's clear. Couple of seconds. How manyof them I have to do to ballance learning a new language(and I'm not sure if I like it eventually)? If I was a system software developer, that would probably be a good choice. I program mostly in high level languages, so maybe not. :)

Maybe it doesn’t matter for small programs, but probably in large programs tracing the control flow would be non trivial, so, as the parent said, over the lifetime of the program it would add up

Is there any language that can save you from control tracing problem? I think that well made architecture is only solution. In fact I would say that C is easier in that respect (if you don't use goto), because all control flow is explicit. In other languages you have exceptions, polymorphism, implicit constructors, destructors (and their order in case of inheritance, templates, etc.

C is dead simple in that respect. If you can't write right concise code no language can help you. However of course, as C is more verbose it is more challanging to structure code well. And to some extend other language can help you move the point where control flow becomes a problem.

The biggest problem in C programming for me is memory management, but maybe it's just a lack of experience. Certainly C++ is convenient with smart pointers and automaticall called destructors.

Anyway, i didn't consider big project a scope here. I wouldn't write realy big programs in wine. I would try to create as small independent parts as possible.

>In other languages you have exceptions, polymorphism, implicit constructors, destructors (and their order in case of inheritance, templates, etc.

Of these, Rust has only destructors :)

It's not just a lack of experience-- Microsoft developers, Chrome developers, Mozilla developers, all have problems with memory management :) https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

It's trivial to fix if you catch it early, and perfectly fine for a tool you run yourself. However if the problem is discovered two years later in production, there will be a forth-and-back until you get at the correct error message, possibly downtime, and if there isn't one you'll be instructing them how to install debug symbols for libX.

This is a very good point. Good testing, good programming practices, good logs are necessary. And it's not only about C. It's not so hard to do better than in Java. xD

Such an error is nobrainer? Yet you deployed your code with several of them?

Understandably you didn’t put your whole effort into a small code example in a HN comment, but a language that allows one to do so without any errors would be big productivity and safety gain.

Of course, in the program like this. It's quite obvious that for a bigger program it would be much harder. I wouldn't use C for a big monolith system or if I had to, I would put much effort in diagnostic features.

I don't write professionaly C code. I use it for my purposes so debugging is easy. I agree that such a problem in a bigger system whithout ability to reproduce environment and debug would be very nasty. However that is matter of context. In bigger system it's more reasonable to buy more safety for price of simplicity, because I doubt any of competitors in the benchmark is as simple as C.

> Not a big deal, because fully functional and 100% correct program wasn't the goal here

Wasn't it? It reminds me about the old article by Strostrup on c/c++ for beginners (I seem to link to this quite often, apologies if it gets repetitive):

https://www.drdobbs.com/learning-standard-c-as-a-new-languag...

One point of using c++ over c is that it should be easier to get a program that is in fact correct - regarding things like closing files etc. (that said conciously leaking some recources ("do and die") could be considered idiomatic c i suppose).

Yes, I consider that memory management is the biggest problem with C. Always the question is what is more valueable to you: simplicity or memory management.

Reply on news.ycombinator.com