4 ms·
Many things "could make sense", but often do not in the common case. Your optimization is a good example for something where jumping through explicit hoops wou
by anyfoo 4y ago
Many things "could make sense", but often do not in the common case.
Your optimization is a good example for something where jumping through explicit hoops would not only be palpable, but even help signify the intent of your code optimization, while protecting common code from nasty surprises.
Otherwise, we could also go back to earlier C days and, for example, let the compiler be silent about assigning a pointer of the wrong type without an explicit cast. That makes sense a lot of times, but still I want the compiler to tell me that I passed a struct foo* where a struct bar* was needed, or worse, a struct foo**.
- KerrAvon 4y agoIt blew my mind (in a bad way) when i went from CodeWarrior to GCC, and suddenly basic pointer typechecking was a minor warning that you had to enable instead of a hard compile error that was on all the time. My takeaway was that Unix people were lax because they didn’t have to worry about corrupting system data structures like we did on classic MacOS, AmigaOS, Windows pre-NT, etc.
- duped 4y agoSure, but I think a lint to warn you that a variable named "size" should be size_t is complete overkill. What I'd rather see are better lints and a better culture around them instead of the cowboy attitude you see in a lot of systems code. Today, lints for C are pretty bad and the default attitude isn't to fix warnings but to disable them when compiling the software. Even worse is when distro maintainers patch the sketchy code instead of the 1p devs doing it right from the beginning. It doesn't matter what your warnings are if the attitude is to ignore them. And in this case, there are several warnings that would tell you the code smells and needs attention.