A critique of "How to C in 2016"
github.com
A critique of "How to C in 2016"
1–10 of 181 posts
Re: A critique of "How to C in 2016"
#2[deleted]
Re: A critique of "How to C in 2016"
#3Aah, this felt like a much-needed piece. The original text was so long, it kind of made my eyes glaze over and I never found the time to do this level of detailed critique. Well done!
Re: A critique of "How to C in 2016"
#4Not to be confused with Ken Thompson.
Re: A critique of "How to C in 2016"
#5> Zeroing memory often means that buggy code will have consistent behavior; by definition it will not have correct behavior. And consistently incorrect behavior can be more difficult to track down.
I agree that using calloc should not be an excuse for writing sloppy initialization code. But in my experience, inconsistently incorrect behaviour (e.g. heisenbugs that tend to appear and disappear depending on the content of some random chunk of uninitialized memory that happens to be in an unfortunate state after malloc) are one of the hardest type of bugs to fix. It's the type of the bug that occasionally happens in production and typically can't be reproduced in a controlled manner in a development environment. I certainly prefer consistently incorrect behavior.
Re: A critique of "How to C in 2016"
#6I'm divided.
I think it is good to share our ideas and our theories with each other because the discourse can stretch our minds and help us better imagine the perspective of another. Dialogue can foster creativity and invention, and an honest argument can embiggen friendships like nothing else.
On the other hand, opinions are like assholes.
Re: A critique of "How to C in 2016"
#7Not to be confused with Ken Thompson.
Almost fell for that....
Re: A critique of "How to C in 2016"
#8This, ladies and gentlemen, is why C gives me the willies. And why this happens:
http://www.cvedetails.com/vulnerability-list/year-2016/month...
Re: A critique of "How to C in 2016"
#9I disagree with many of the arguments. Many of them are ignoring the reality of today.
One example:
> If you want bytes, use unsigned char. If you want octets, use uint8_t
Bytes and octets are the same today. I never came across a system where this wasn't true. I was never told about a system where this wasn't true. I wasn't even told that there once were systems where this wasn't true until fairly recently.
Re: A critique of "How to C in 2016"
#10What's up with creating "empty" repositories for articles? Isn't there a better solution? I think using gist would be more suitable if you want the article to be attached to your github username...