But it isn't even April 1 yet!
This is truly a BAAAD joke.
So GIT is not implemented in C? Or C++?
Git's list of banned C functions
91–100 of 639 posts
Re: Git's list of banned C functions
#92Earlier quoted context omitted.
Why make it harder, and why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made?
> Why make it harder Because there is no way for a commit message to become outdated or detached from what it talks about, both of which are very much issues with comments. > why make it impossible to update if there are other suggested alternatives that are available since whenever the commit was made? Because that doesn't really matter.
> Because that doesn't really matter.
Ok, so maybe rather than have this file we should run “git log | grep BANNED” and build a list of functions from that? Or maybe we could change all error messages to be “go look at the commit history to work out why this happened”.
No? Maybe putting context in source files (or better yet, an error message!) rather than in a side channel like the commit message has value when it comes to understanding and updating, and it won’t be lost under the weight of future commits.
Re: Git's list of banned C functions
#93It would be interesting to see the rationale behind these bans, and what the suggested alternatives are. Some are obvious, like `strcpy`, but I can't remember what the problem with `sprintf` or the time functions are. If you are doing something like `sprintf(buffer, "%f, %f", a, b)`, yes it is tricky to choose the size of buffer frugally, but if you replace that by `ftoa` and constructing the string by hand, you are…
sprintf() warnings have gotten pretty sophisticated these days. I discovered GCC's -Wformat-overflow the other day. It complained that the buffer for a date string wasn't big enough; e.g., sprintf(buf, "%04d-%02u-%02u", year, month, day), where year, month, and day are 16-bit shorts, and buf was probably eleven or twelve bytes.
It may actually be a bug that I got the warning, because the range of each input was checked, and I think the compiler is supposed to be smart enough to remember that.
Re: Git's list of banned C functions
#94Its 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.
If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…
My favorite assembly foot gun was a guy I worked with had a cute routine. You had a call to the routine, followed by a null terminated string after that. The routine would spit the string to the terminal. And then return to the location after the string.
He had some bug where in one place it returned to the start of the string, executed it, and kept going. The end result just happened to be a nop. Had been like that in production for a couple of years.
Re: Git's list of banned C functions
#95I love seeing "strncpy" right after "strcpy."
If someone wants some fun, try this:
1. Slurp up all the FOSS projects that extend back to 90s or early 2000s.
2. Filter by starting at earliest snapshot and finding occurrences of strcpy and friends who don't have the "n" in the middle.
3. For those occurrences, see which ones were "fixed" by changing them to strncpy and friends in a later commit somewhere.
4. See if you can isolate that part of the code that has the strncpy/etc. and run gcc on it. Gcc-- for certain cases (string literals, I think)-- can report a warning if "n" has been set to a value that could cause an overflow.
I'm going to speculate that there was a period where C programmers were furiously committing a large number of errors to their codebases because the "n" stands for "safety."
Re: Git's list of banned C functions
#96Its 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.
If you list the languages you use, I'd be happy to point out the "footguns" in each of them. For all the warts on C, there really is no language that can compete for what it has accomplished over ~50 years. Recall that during the rise of C, people were writing machine code on punch cards. Assembly -> Machine code has far more footbullets than C, it is a tradeoff between hand holding and tiny fast code. Wow, this blew…
Yeah there are footguns in every language. But this is not a boolean question about the presence of footguns, this is about how much one has to know to be able to handle a language safely.
I know C/C#/Python/Rust/Javascript.
After a decade of using C I am still not totally sure if I didn't dangle a pointer somwhere in precisely the wrong way to create havoc. And yeah, that means I have to get better, etc. But that is not the point. The point is, that even with a lot of experience in the language you can still easily shoot yourself into the foot and don't even notice it.
Meanwhile after a month of using Rust I felt confident that I didn't shoot myself in the foot, because I know what the compilers e.g. ownership guarantuees. While in C shooting myself into the foot happen quite often in Rust I would have to specifically find a way to shoot myself into the foot without the compiler yelling at me, and quite frankly I havent found such a way yet.
Javascript is odd, because the typesystem has quite a few footguns in it. This is why such things like Elm or Typescript exist: to avoid these footguns.
I don't want to take away from the accomplishments of C, and I still like the language, but to claim it is equally likely in all languages to shoot yourself into the foot is not true.
Re: Git's list of banned C functions
#97Earlier quoted context omitted.
But why put that info in commit message instead of a comment in the file itself?
Because comments can be tedious and get out of sync with the repo. Why not check the git history? I wish more repos could be like this!
> Why not check the git history?
Because that is effort every person who uses the file has to do over and over again, whereas maintaining the file is effort that has to be done once by one person.
Re: Git's list of banned C functions
#98It would be great if the BANNED() macro could suggest the correct function to use.
Re: Git's list of banned C functions
#99Earlier quoted context omitted.
It's not really complacency: it's that the standard library is intentionally minimalistic to maintain portability and backwards compatibility. If you want sensible string handling, it's usually best to use a high level utility library like GLib( https://developer.gnome.org/glib/stable/ ) or Apache Portable Runtime( http://apr.apache.org/ ), or roll your own safe string type (preferably non-null terminating)
No, if you want sensible string handling, the sane choice is usually to choose to use a language that is not C. Not always, but definitely usually.
It’s not hard to have strings like you do in other languages in C. It is hard when you treat char foo[] as if it was a string object like you have in JavaScript or Java or Python. C strings are just chunks of memory terminated by \0. They can still be mildly useful that way but if you actually want to do string operations you need to use a library designed for the problem (variable length, storing length with the object, Unicode support, etc.). Problem is that most people don’t start with such a library so they end up doing the hard work themselves in an ad hoc manner.
You can’t fuck up String(“Hello “) + String(“world”) but you can definitely fuck up strcat(buf, “Hello “); strcat(buf, “world”);.
Re: Git's list of banned C functions
#100Its 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.
This is a lot like how in JavaScript you have footguns like the with statement or in Python 2 where you have Unicode issues, etc. I am sure we could definitely a new C standard that excludes these functions as obsolete, but the linked header file is a pretty sensible interim solution. C is an old language and it’s kind of amazing that code written 30 years ago can still by and large be compiled by a modern compiler.…
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.