5 ms·

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

• ianai 7y ago
  I hope it grows through community effort. This is a good sanity check sort of thing.
  • deleted 7y ago
    [deleted]
• Kaveren 7y ago
  Maybe gets doesn't need to be banned because it got removed in C11 and at least gcc issues a warning on use.
• asveikau 7y ago
  I don't see a huge problem with strtok as long as it isn't a multi threaded program. It is not in gets territory which is literally impossible to use correctly.
  • slovenlyrobot 7y ago
    I can't remember what's wrong with it, but it's responsible for about eleventy billion CVEs over the years
  • lholden 7y ago
    "I don't see a huge problem with insert thing here as long as it isn't a multi threaded program." Usually a bad omen. :)
  • bhk 7y ago
    Synchronous reentry is a problem. Say some loop using strtok calls a function... how do you know that that function doesn't use strtok (or call another function that does...). Any use of non-const static variables in general has this problem, and strtok is just one example.
    • derefr 7y ago
      > Say some loop using strtok calls a function... how do you know that that function doesn't use strtok (or call another function that does...). I’m constantly surprised that C isn’t specified in such a way that lack-of-reentrancy can be determined at compile time. You’d “just” need a symbol table, sort of like the debug symbol table, in each compiled object, holding for each visible symbol the set of function calls marked `__no_reenter` that are predominated by that symbol in control flow. (Yes, some functions do computed jumps, like with longjmp. Just implicitly label those functions __no_reenter unless the programmer explicitly labels them __reenter!)
      • asveikau 7y ago
        The problem isn't exactly reentry. It's that the function, having already exited, has modified global state, and it needs the same state to be there on the next call. If another call is interleaved (another callee with its own strtok loop) then the state is overwritten with the inner loop, and your own next call won't have its expected contents. Whereas with a term like reentry I think of two strtok frames on the stack at the same time, which is not possible. I think it's a bit easier to conceptualize with a function that produces a simple return value in a static buffer. Take getpwnam(). It fills a global structure with info about a given user. So you may keep a pointer to that on your stack. Then you call some other function foo(). foo looks up another user. Suddenly you can't rely on that other call to getpwnam() not having overwritten the data in the result you got back the first time.
        • bhk 7y ago
          Ah, yes. What I described wasn't reentry. A reentrant function using strtok could exhibit this problem, but it applies more widely than that.
    • userbinator 7y ago
      how do you know that that function doesn't use strtok (or call another function that does...). The same way you know a lot of other things about the codebase: By reading and understanding it. Given what strtok() is used for, it's almost always going to be working on a single context at any one time.
  • tlb 7y ago
    git does use multiple threads for some longer operations, like gc and pack, so using strtok would be a disaster.
  • missblit 7y ago
    Might as well just use strtok_r everywhere and not worry about if you're using strok safely or not.
  • tropo 7y ago
    You can safely use gets on trusted input. For example, your program might create a pipe or socketpair to communicate between the processes that result from a call to fork. The stdout of one process feeds into the stdout of the other process. Unless you have an insane gets implementation that writes the bytes backwards, you can also safely use it on untrusted input. Simply place a guard page at the end of the buffer. You can do the call from a forked child that you let die, taking notice of the problem in the parent. On systems without threading (because of locks in libc) you can do a longjmp to recover.
• jpjuni0r 7y ago
  I'm curious how sscanf is considered bad?
  • saagarjha 7y ago
    scanf(“%s”, …) can cause a buffer overflow.
    • mort96 7y ago
      It sucks that there's no scanf("%.*s"), where you give the buffer length as a separate argument. The fact that it's in a string literal also makes using a compile-time constant really ugly.
    • claystu 7y ago
      You can overflow buffers all sorts of ways in C.