Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Git's list of banned C functions

github.com

Post reply on HN
Print view View original

231–240 of 639 posts

Re: Git's list of banned C functions

#231

Post by dpedu »

barnaclejive wrote: post #204
blitz_skull wrote: post #150

Earlier quoted context omitted.

I disagree. Commits messages exist for the very purpose of adding context to your code base. If you added for something that needs context, sure MAYBE add a comment, but I really pray that I'm going to find a few paragraphs disambiguating the problem within a git commit. If I'm _really_ lucky, maybe I find a PR number or Jira ticket reference as well. If you're truly clueless as to what could be substituted for these…

So, you are tied to Git for eternity to preserve documentation? Might work in practice for a long time, but Git is a version control system, not a documentation system.

For developer documentation - yes, absolutely!

Re: Git's list of banned C functions

#232

Post by coliveira »

munchbunny wrote: post #143
paultopia wrote: post #17

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.

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…

Null terminated strings are remnants of an era when computers had little memory available. So, at the time it seemed smart to discard the length field and use a single byte-sized terminator (null). If you are writing an operating system for a machine with little memory to spare, this seems like a good decision. Of course things are very different now when memory is not a problem and the goal is safety.

Re: Git's list of banned C functions

#233

Post by boolemancer »

maerF0x0 wrote: post #62
SavantIdiot wrote: post #57

Earlier quoted context omitted.

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…

Not that I dont believe there are any, but I'd love to hear your perspective... Go (golang)

defer having function scope instead of, well, scope scope.

Using defer to unlock locks can lead to some fun deadlocks if you don't realize the issue with the scope, and it's completely unintuitive to someone with experience with other implementations of similar concepts.

Re: Git's list of banned C functions

#234

Post by GordonS »

ggregoire wrote: post #142
IgorPartola wrote: post #83

Earlier quoted context omitted.

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.…

> in JavaScript you have footguns like the with statement I've been coding in JS on a daily basis for more than 10 years and today I learned there is a `with` statement in JS. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Edit: well, seems like it's been deprecated/forbidden since ES5 (2009), so it makes sense I've never seen it.

And me around 20 years - also never even heard of the `with` statement! I think to qualify as a footgun, people actually need to be using it in the real world.

Re: Git's list of banned C functions

#235

Post by varjag »

burnished wrote: post #187
mkipper wrote: post #86

Earlier quoted context omitted.

citation needed I'm sure there's a lot of important things that rely on COBOL, but by most definitions of "critical", I think this is way off the mark.

COBOL is still used in many banking systems such as ATMs. These are 'critical' systems by most any definition of the word 'critical'.

That's a hugely broad definition of critical, enough to encompass most of business and finance software.

Re: Git's list of banned C functions

#236

Post by syncsynchalt »

dahfizz wrote: post #23
captainmuon wrote: post #11

It 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…

This was my reaction as well. Banning strncpy just encourages haphazard manual copying.

strncpy doesn't do what you think it does (it is not analogous to strncat). strncpy does not terminate strings on overflow. In C terms, it is not actually a string function and shouldn't be named with `str`.

snprintf or nul-plus-strncat do what you want, but snprintf has portability problems on overflow. Most projects I've been on rely on strlcpy (with a polyfill implementation where not available).

Re: Git's list of banned C functions

#237

Post by gravypod »

InvOfSmallC wrote: post #103
jchw wrote: post #45

Earlier quoted context omitted.

Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…

I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. The university decided to explain C to first year student without previous experience. My feedback was to do a precourse in Python to let them relax a bit with programming as a concept and then teach C in a second course.

Sorry to bug you since this is unrelated. I'm a huge fan of teaching others and I was wondering how you got to be an external lecturer at a college? I'd love to teach classes related to software engineering and data structures. Would you mind emailing me (in my profile) about this?

Re: Git's list of banned C functions

#238

Post by skeletal88 »

adrianmonk wrote: post #97
chris_wot wrote: post #71

Earlier quoted context omitted.

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.

Someone here commented to use git blame to find the commit that banned the functions and read the commits. These people making the suggestions.. must hate other people and their time. Also, what if someone.. for example runs a code formatter on the file, making git blame useless? Is it really so difficult to make a manual or explain properly in the comments about what replacements to use?

Re: Git's list of banned C functions

#239

Post by tomjakubowski »

gilbetron wrote: post #114
jancsika wrote: post #95

I 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…

Meh, most of us understood the sharp edges of strings pretty well. Before, we'd check the len of strings before strcpy, strncpy let us do it without doing that, and just slap a 0 in if needed. Safe? No. Better? A bit. Do I ever want to do string manipulation again with C? Nope.

Understanding the sharp edges is one thing. Being able to avoid them in practice is another. The history of memory safety problems in C string handling, especially involving strcpy/strncpy, strongly suggests to me that they're unavoidable even for C programmers who are skilled, knowledgeable, and experienced.

Re: Git's list of banned C functions

#240

Post by throwaway09223 »

_kst_ wrote: post #68
throwaway09223 wrote: post #37

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.

strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array ( if you tell it the correct length for that array), but it's not a true string function, and it can leave the target unterminated and therefore not a valid string. http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...

In the interest of satisfying pedantry I think we can agree that strncpy() is intended to be a safer strcpy() for a subset of uses.

As you say, it does in fact obviate some errors. A value judgement as to which behaviors are more or less safe may be subjective, but the intent is not.

Post reply on HN