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

111–120 of 639 posts

Re: Git's list of banned C functions

#111

Post by kzrdude »

attractivechaos wrote: post #66
lights0123 wrote: post #48

Earlier quoted context omitted.

https://github.com/git/git/commit/e488b7aba743d23b830d239dcc... Yes: > we provide a compat version, so it's always available

This gets me interested. Link [1] below shows their implementation of strlcpy(). This is a questionable implementation. With strncpy, the source string "src" may not be NULL terminated IIRC. The git implementation requires "src" to be NULL terminated. If not, an invalid read. EDIT: according to the strlcpy manpage [2], "src" is required to be NULL terminated, so strlcpy imposes more restrictions and is not a proper r…

You have found the answer - strlcpy is not a replacement for strncpy at all (it's arguably a safer version of strcpy), and git people didn't invent this, it's the existing BSD strlcpy interface.

Re: Git's list of banned C functions

#112

Post by tinus_hn »

cle wrote: post #13
drfuchs wrote: post #6

It would be nice if the error messages generated would suggest replacement functions that they deem appropriate. I see that I'm not supposed to use gmtime, localtime, ctime, ctime_r, asctime, and asctime_r; but what do they think I should use?

From the commit messages > The ctime_r() and asctime_r() functions are reentrant, but have no check that the buffer we pass in is long enough (the manpage says it "should have room for at least 26 bytes"). Since this is such an easy-to-get-wrong interface, and since we have the much safer strftime() as well as its more convenient strbuf_addftime() wrapper, let's ban both of those. ( https://github.com/git/git/commit/…

Strangely there is no mention of strtok which has a similar issue.

Re: Git's list of banned C functions

#113

Post by SavantIdiot »

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)

Well, shit. Got me there.

Re: Git's list of banned C functions

#114

Post by gilbetron »

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.

Re: Git's list of banned C functions

#115

Post by jchw »

masklinn wrote: post #69
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.) (…

> Technically C11 has strcpy_s and strcat_s "Theoretically" is the word you're looking for: they're part of the optional Annex K so technically you can't rely on them being available in a portable program. And they're basically not implemented by anyone but microsoft (which created them and lobbied for their inclusion).

I didn’t know that it was Microsoft that lobbied for them; that perplexes me since I thought Microsoft’s version of them were a bit different (for example, I think C11’s explicitly fail on overlapping inputs where Microsoft specifies undefined behavior) and because Microsoft didn’t bother supporting C99 for the longest time. (Probably still don’t, since VLA was not optional in C99, IIRC. I think Microsoft was right to avoid VLA, though.)

Re: Git's list of banned C functions

#116

Post by fsociety »

xondono wrote: post #89
lmilcin wrote: post #67

To respond to some of the comments. It is not that there is anything intrinsically wrong with these functions. You can technically use all of them and I have been using all of them, safely, for decades. The issue is they are huge traps to the point that in a larger piece of software one can say "well, it's just not worth it". You can go much, much, much further than that. In couple embedded projects I worked some of…

Anything enforcing MISRA has essentially (almost) no way of allocating memory at runtime.

It’s funny, I worked exclusively with MISRA at the start of my career. Eventually I started a job at a FAANG and received quizzical comments on why I implemented a memory arena.

The argument was to allocate memory freely and let it pool memory as necessary. Fair enough, it was simpler and fit the standard expectation of development.

The issue is that if you talk with the allocator team they complain of not being able to fix performance issues fast enough due to allocations firing off left and right in the middle of a request.

I never realized that my view of C programming is heavily influenced by MISRA until your comment.

I know game engine programming follows a similar, perhaps unspoken, convention.

Re: Git's list of banned C functions

#117

Post by ritmatter »

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.

+1, my university's program seemed to work well with "program anything" (Python), "program with objects" (Java), "program some cool lower-level stuff" (C)

Re: Git's list of banned C functions

#118

Post by tedunangst »

rrauenza wrote: post #107
_kst_ wrote: post #68

Earlier quoted context omitted.

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

I never could really understand the point of strncpy()... we always end up wrapping to deal with writing an unterminated string. Was it intended for fixed length records?

It is for fixed length records, which is why it also zeroes the remaining space.

Re: Git's list of banned C functions

#119

Post by [deleted] »

orf wrote: post #92
masklinn wrote: post #77

Earlier quoted context omitted.

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

[deleted]

Re: Git's list of banned C functions

#120

Post by abetusk »

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 correctly, it's sometimes hard
  for a reader to verify this without hunting through the
  code. If you're thinking about using it, consider instead:

    - strlcpy() if you really just need a truncated but
      NUL-terminated string (we provide a compat version, so
      it's always available)

    - xsnprintf() if you're sure that what you're copying
      should fit

    - strbuf or xstrfmt() if you need to handle
      arbitrary-length heap-allocated strings
I just did a search on the keywords 'banned' and 'strncpy' [2]

[0] https://lore.kernel.org/git/20180724092828.GD3288@sigill.int...

[1] https://lore.kernel.org/git/20190103044941.GA20047@sigill.in...

[2] https://lore.kernel.org/git/20190102093846.6664-1-e@80x24.or...

[3] https://lore.kernel.org/git/?q=banned+strncpy

Post reply on HN