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

31–40 of 639 posts

Re: Git's list of banned C functions

#31

Post by dgentile »

attractivechaos wrote: post #16

I wonder how they copy strings with strcpy and strncpy both banned. strlcpy? But it is not conforming to major standards. Or just memcpy with extra code?

Edited: Looks like they have safe alternatives: "

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

Re: Git's list of banned C functions

#32

Post by smasher164 »

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.

From the commit message:

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

Re: Git's list of banned C functions

#33

Post by azurezyq »

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.

maybe this https://github.com/git/git/blob/master/strbuf.h ?

Re: Git's list of banned C functions

#35

Post by Aanok »

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…

The trouble with printf-family functions is their variadic nature. If the arguments don't match the format string, you can wreak all sorts of havoc.

A fun exercise you can do is put a "%s" in the format string, omit the string argument and see what happens to the stack.

Re: Git's list of banned C functions

#36

Post by ben_bai »

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.

strlcpy is the safe way, that is used by git.

Re: Git's list of banned C functions

#37

Post by throwaway09223 »

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.

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.

Re: Git's list of banned C functions

#39

Post by [deleted] »

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.

[deleted]
Post reply on HN