151–160 of 639 posts
Turns out you just can't use them when you contribute code to the Git project. That makes sense, and seems reasonable.
Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.
As someone who learned C as their first language, strings in every single language after that have felt like cheating. "What? You mean I can type an arbitrary string and it works? I don't need to worry about terminators or the amount of memory I've allocated? You can concatenate two strings with +?!? What is this magic?"
I still love C, but I'd do my best not to have to write anything serious with it again.
Earlier quoted context omitted.
It is for fixed length records, which is why it also zeroes the remaining space.
Arguably naming it with “str” is itself a security vulnerability.
Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.
Earlier quoted context omitted.
It amuses me that HN hates JS so much, that even a topic about problems with C turns into a JS-bashing thread. Also, I just want to remind you that JS isn't just React. There are plenty of libraries written in C that introduce breaking changes over the course of 3 years. Nothing will stop people from finding ways to complain about JS though, I know. The hate-boner is very real.
I think in most cases it's probably not hate but a deep, deep love.
Assorted musing : Rust, OCaml under C disguise.
Earlier quoted context omitted.
Many of C's problems relate to string handling. These are all legacy functions which have been replaced with safe alternatives many decades ago. strcpy() was replaced with a safer strncpy() and in turn has been replaced with strlcpy(). The list is a ban of the less safe versions, where more modern alternatives exist.
Why are these functions deprecated in favor of others but not removed? I know in Javascript this can happen so as to not break older websites, but in a compiled language this shouldn't be a problem right?
The reality of C is that if we deprecated every objectionable function in the stdlib we wouldn't have anything left.
Earlier quoted context omitted.
Many of C's problems relate to string handling. These are all legacy functions which have been replaced with safe alternatives many decades ago. strcpy() was replaced with a safer strncpy() and in turn has been replaced with strlcpy(). The list is a ban of the less safe versions, where more modern alternatives exist.
Why are these functions deprecated in favor of others but not removed? I know in Javascript this can happen so as to not break older websites, but in a compiled language this shouldn't be a problem right?
The Git Mailing List Archive on lore.kernel.org (found in the README from the git mirror on GitHub) has more context [0] [1] [2]. From Jeff King on 2018-07-24: The strncpy() function is less horrible than strcpy(), but is still pretty easy to misuse because of its funny termination semantics. Namely, that if it truncates it omits the NUL terminator, and you must remember to add it yourself. Even if you use it correct…
https://github.com/git/git/commits/master/banned.h
(Git development is done by emailing patches. Those patches include the git commit message, which we can see just by looking at the history of the file. Sometimes there's additional discussion on the ML, but the most important details are in the commit message because the git development team is very disciplined about that.)
Earlier quoted context omitted.
The decision to make C strings null terminated with implied length instead of length + blob continues to trip us up, 30+ years later. There's a good reason the "safe" versions of those functions all take length parameters. But way back when this approach was chosen, I don't think the state of the art could fully predict this outcome. But also, "strings" and "time" are actually very complex concepts, and these functio…
30+ years -> 50+ years Funny mind thing to forget to increment counters each year.