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

251–260 of 639 posts

Re: Git's list of banned C functions

#251

Post by syncsynchalt »

kgrimes2 wrote: post #197

Can a C guru provide a TL;DR of why these are bad?

    - strcpy: no bounds check
    - strcat: no bounds check
    - strncpy: does not nul-terminate on overflow
    - strncat: no major issues, probably to force usage of strlcat
    - sprintf: no bounds check
    - vsprintf: no bounds check
    - gmtime: returns static memory
    - localtime: returns static memory
    - ctime: no bounds check
    - ctime_r: no bounds check
    - asctime: returns static memory
    - asctime_r: no bounds check
The str functions all have safer alternatives. The time functions have reentrant alternatives, and/or alternatives that provide a bounds check.

Re: Git's list of banned C functions

#252

Post by reasonabl_human »

PoignardAzur wrote: post #230
orwin wrote: post #184

Earlier quoted context omitted.

In my school, we had two days to understand the basics of text editors, git (add, commit, rebase, reset, push) and basic bash functions (ls, cd, cp, mv, diff and patch, find, grep...) + pipes, then a day to understand how while, if/else and function calls work, then a day to understand how pointer work, then a day to understand how malloc(), free() and string works (we had to remake strlen, strcpy, and protect them).…

Ooh, the Epitech cursus. Nice. Also, I'd say "not having segfaults" is the hardest thing to get right when you're going through that.

Eh, not really possible in my experience... more like ‘incidentally becoming a gdb wizard in order to be productive with C’!

Re: Git's list of banned C functions

#253

Post by ksherlock »

skeletal88 wrote: post #238
adrianmonk wrote: post #97

Earlier quoted context omitted.

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

git blame --ignore-rev / --ignore-revs-file

Re: Git's list of banned C functions

#254

Post by cestith »

pix64 wrote: post #245
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.

strlcpy() isn't standard. You have to provide your own implementation if you want your code to be portable.

This is something git does. That's why they prefer it - it's available to git everywhere.

Re: Git's list of banned C functions

#255

Post by hctaw »

ironmagma wrote: post #194
hctaw wrote: post #179

Earlier quoted context omitted.

That assumes you have a header, which only exists at compile time for the developer. The running program knows nothing about it.

Why would a program need to know (e.g.) the details of what system calls or stdlib functions that a procedure it invokes uses? Aren’t C functions pretty well separated from each other except for the odd signal handler and assuming a stable ABI? In my view most of the issues with C are semantics within the function blocks.

The program doesn't "know" anything. The executable has a header used by the loader that tells it to use libc. If the libc version does not contain the symbols that the program expects or the symbols do not have compatible definitions (meaning identical function signature and ABI, including struct layout) the program will probably crash. If the program links against any shared libraries they'll use the same version of libc that's loaded with the executable.

There are ways around this that are varying degrees of acceptable. Versioning libc itself is outside the scope of the language, since it really depends on how the system linkers and loaders are implemented.

Re: Git's list of banned C functions

#257

Post by lvs »

kazinator wrote: post #198
InvOfSmallC wrote: post #103

Earlier quoted context omitted.

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.

> I teach at university as external lecturer. Teaching strings in C is the hardest thing I have to do every time. But if you keep up the good work you will one day go from extern void *lecturer; to static const lecturer;

More commonly

     volatile unsigned short lecturer;

Re: Git's list of banned C functions

#258

Post by bobbyi_settv »

munchbunny wrote: post #193
retrac wrote: post #166

Earlier quoted context omitted.

For reasons that were never clearly articulated, the prefix approach was considered odd, backwards, and to have numerous downsides, at least where I learned C. In hindsight, I can only cringe at that attitude. Strings as added in later Pascal, about 40 years ago now, were memory safe in a way that C strings still are not.

The prefix approach turns the neat "strings are just character arrays are just pointers" pattern into something a lot more clunky, because now you've got this really basic data type that is actually a struct and now you have to have an opinion on how wide the length value is and short strings get a lot of memory overhead in just lengths, and so on. In hindsight, I think the complexity is worth the safety, but I could…

It doesn't just buy safety. It also makes it possible to include null bytes inside of strings.

Re: Git's list of banned C functions

#259

Post by abetusk »

js2 wrote: post #159
abetusk wrote: post #120

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…

Psst: 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.)

Ha, yep, whoops
Post reply on HN