Banned C standard library functions in Git source code

Yes, and interestingly, because even when used correctly they "complicate audits". This is an interesting use of preprocessor macros, I'm strongly debating introducing something like this at work.

Re: Banned C standard library functions in Git source code

#5

Post by zsrxx » Sun, Aug 25, 2019, 2:25 PM UTC

jepler wrote: post #2

I guess they care too much about portability to use "pragma GCC poison"?

Wanting code to compile on something other than gcc is not "caring too much", it's being responsible

Re: Banned C standard library functions in Git source code

#6

Post by kbumsik » Sun, Aug 25, 2019, 2:25 PM UTC

opticfluorine wrote: post #4

kbumsik wrote: post #3

Because of possible string buffer overflow?

Yes, and interestingly, because even when used correctly they "complicate audits". This is an interesting use of preprocessor macros, I'm strongly debating introducing something like this at work.

I'm not an expert in C, but then what's the issue with strncpy() or any "n" functions? It prevents overflow AFAIK. Also what is the alternative (memcpy?) and why?

Re: Banned C standard library functions in Git source code

#7

Post by MuffinFlavored » Sun, Aug 25, 2019, 2:26 PM UTC

For anybody else:

Why is strncpy insecure?

https://stackoverflow.com/questions/869883/why-is-strncpy-in...

> strncpy() doesn't require NUL termination, and is therefore susceptible to a variety of exploits.

Re: Banned C standard library functions in Git source code

#8

Post by slovenlyrobot » Sun, Aug 25, 2019, 2:27 PM UTC

That's a surprisingly small list, missing e.g. sscanf / gets / strtok / all the other "usual suspects" at least

Re: Banned C standard library functions in Git source code

#9

Post by susam » Sun, Aug 25, 2019, 2:28 PM UTC

kbumsik wrote: post #6

opticfluorine wrote: post #4

Earlier quoted context omitted.

Yes, and interestingly, because even when used correctly they "complicate audits". This is an interesting use of preprocessor macros, I'm strongly debating introducing something like this at work.

I'm not an expert in C, but then what's the issue with strncpy() or any "n" functions? It prevents overflow AFAIK. Also what is the alternative (memcpy?) and why?

strncpy() does not guarantee that the copied string would be terminated with a null byte ('\0'). For a call that looks like strncpy(dst, src, n), if there is no null byte in the first n bytes of src, the string copied to dst would also not contain a null byte.

Here is an example code to demonstrate the problem:

  #include 
  #include 

  int main()
  {
      char a[] = "01234567";
      strncpy(a, "foobar", 4);
      printf("%.8s\n", a);
      return 0;
  }

Here is the output:

  $ cc -std=c89 -Wall -Wextra -pedantic foo.c && ./a.out
  foob4567

A C89-conforming alternative I use is a macro like this that guarantees '\0'-termination as the first thing:

  #define strcp(a, b, c) (a[0] = '\0', strncat(a, b, c - 1))

An example from my code: https://github.com/susam/uncap/blob/master/uncap.c#L78-L87

Here is how to use it:

  #include 
  #include 

  #define strcp(a, b, c) (a[0] = '\0', strncat(a, b, c - 1))

  int main()
  {
      char a[] = "01234567";
      strcp(a, "foobar", 4);
      printf("%.8s\n", a);
      return 0;
  }

Here is the output:

  $ cc -std=c89 -Wall -Wextra -pedantic foo.c && ./a.out
  foo

Re: Banned C standard library functions in Git source code

#10

Post by ianai » Sun, Aug 25, 2019, 2:28 PM UTC

slovenlyrobot wrote: post #8

That's a surprisingly small list, missing e.g. sscanf / gets / strtok / all the other "usual suspects" at least

I hope it grows through community effort. This is a good sanity check sort of thing.