No strcpy either

 (daniel.haxx.se)

85 points | by firesteelrain 2 hours ago

9 comments

  • t43562 1 hour ago
    I've always wondered at the motivatons of the various string routines in C - every one of them seems to have some huge caveat which makes them useless.

    After years I now think it's essential to have a library which records at least how much memory is allocated to a string along with the pointer.

    Something like this: https://github.com/msteinert/bstring

    [-]
    • lesuorac 21 minutes ago
      It's from a time before computer viruses no?

      But also all of this book-keeping takes up extra time and space which is a trade-off easily made nowadays.

    • formerly_proven 49 minutes ago
      strncpy is fairly easy, that's a special-purpose function for copying a C string into a fixed-width string, like typically used in old C applications for on-disk formats. E.g. you might have a char username[20] field which can contain up to 20 characters, with unused characters filled with NULs. That's what strncpy is for. The destination argument should always be a fixed-size char array.

      A couple years ago we got a new manual page courtesy of Alejandro Colomar just about this: https://man.archlinux.org/man/string_copying.7.en

      [-]
      • Cyph0n 31 minutes ago
        strncpy doesn’t handle overlapping buffers (undefined behavior). Better to use strncpy_s (if you can) as it is safer overall. See: https://en.cppreference.com/w/c/string/byte/strncpy.html.

        As an aside, this is part of the reason why there are so many C successor languages: you can end up with undefined behavior if you don’t always carefully read the docs.

      • ufo 46 minutes ago
        A big footgun with strncpy is that the output string may not be null terminated.
        [-]
        • kccqzy 39 minutes ago
          Yeah but fixed width strings don’t need null termination. You know exactly how long the string is. No need to find that null byte.
          [-]
          • ninkendo 29 minutes ago
            Until you pass them as a `char *` by accident and it eventually makes its way to some code that does expect null termination.

            There’s languages where you can be quite confident your string will never need null termination… but C is not one of them.

            [-]
          • Sharlin 26 minutes ago
            Good luck though remembering not to pass one to any function that does expect to find a null terminator.
            [-]
            • andrepd 20 minutes ago
              Seriously. We have type systems and compilers that help us to not forget these things. It's not the 70s anymore!
              [-]
              • kccqzy 13 minutes ago
                Seriously. Use `char[20]` instead of `char*` as the type if that helps you remember.
  • swinglock 1 hour ago
    I'm surprised curlx_strcopy doesn't return success. Sure you could check if dest[0] != '/0' if you care to, but that's not only clumsy to write but also error prone, and so checking for success is not encouraged.
    [-]
    • jutter 38 minutes ago
      This is especially bizarre given that he explains above that "it is rare that copying a partial string is the right choice" and that the previous solution returned an error...

      So now it silently fails and sets dest to an empty string without even partially copying anything!?

    • AlexeyBrin 1 hour ago
      I guess the idea is that if the code does not crash at this line:

          DEBUGASSERT(slen < dsize);
      it means it succeeded. Although some compilers will remove the assertions in release builds.

      I would have preferred an explicit error code though.

  • Scubabear68 1 hour ago
    From the article:

    > It has been proven numerous times already that strcpy in source code is like a honey pot for generating hallucinated vulnerability claims

    This closing thought in the article really stood out to me. Why even bother to run AI checking on C code if the AI flags strcpy() as a problem without caveat?

    [-]
    • CGamesPlay 1 hour ago
      It's not quite as black and white as the article implies. The hallucinated vulnerability reports don't flag it "without caveat", they invent a convoluted proof of vulnerability with a logical error somewhere along the way, and then this is what gets submitted as the vulnerability report. That's why it's so agitating for the maintainers: it requires reading a "proof" and finding the contradiction.
    • saagarjha 1 hour ago
      Because people are stupid and use AI for things it is not good at.
      [-]
      • Tempest1981 1 hour ago
        > people are stupid

        people overestimate AI

        [-]
        • lesuorac 7 minutes ago
          Its weird though because looking through the hackone reports in the slop wiki page there aren't actually reproduction steps. It's basically always just a line of code and an explanation of how a function can be mis-used but not a "make a webserver that has this hardcoded response".

          So like why doesn't the person iterate with the AI until they understand the bug (and then ultimately discover it doesn't exist)? Like have any of this bug reports actually paid out? It seems like quickly people should just give up from a lack of rewards.

          [-]
          • amenhotep 1 minute ago
            As long as the number of people newly being convinced that AI generated bounty demands are a good way to make money equals or exceeds the number of people realising it isn't and giving up, the problem remains.

            Not helped, I imagine, that once you realise it doesn't work, an easy pivot is to start convincing new people that it'll work if they pay you money for a course on it.

    • Sharlin 24 minutes ago
      Because these people who run AI checks on OSS code and submit bogus bug reports either assume that AIs don't make mistakes, or just don't care if the report is legit or not, because there's little personal cost even if it isn't.
  • pama 1 hour ago
    Congrats on the completion of this effort! C/C++ can be memory safe but take some effort.

    IMHO the timeline figure could benefit in mobile from using larger fonts. Most plotting libraries have horrible font size defaults. I wonder why no library picked the other extreme end: I have never seen too large an axis label yet.

    [-]
    • Tempest1981 1 hour ago
      Yes, the graph font-sizes seem intended for printing them on a single sheet of paper, vs squeezed into a single column in a blog.
    • saagarjha 1 hour ago
      Removing strcpy from your code does not make it memory safe.
  • loeg 1 hour ago
    A weird Annex-K like API. The destination buffer size includes space for the trailing nul, but the source size only includes non-nul string bytes.

    I don't really think this adds anything over forcing callers to use memcpy directly, instead of strcpy.

  • stabbles 1 hour ago
    Apart from Daniel Sternberg's frequent complaints about AI slop, he also writes [1]

    > A new breed of AI-powered high quality code analyzers, primarily ZeroPath and Aisle Research, started pouring in bug reports to us with potential defects. We have fixed several hundred bugs as a direct result of those reports – so far.

    [1] https://daniel.haxx.se/blog/2025/12/23/a-curl-2025-review/

    [-]
  • TZubiri 48 minutes ago
    LMAO

    After all this time the initial AI Slop report was right:

    https://hackerone.com/reports/2298307

    [-]
    • lesuorac 11 minutes ago
      ?

      Nonce and websockets don't appear at all in the blog post. The only thing the ai slop got right is that by removing strcpy curl will get less issues [submitted about it].

  • snvzz 1 hour ago
    The AI chatbot vulnerability reports part sure is sad to read.

    Why is this even a thing and isn't opt-in?

    I dread the idea of starting to get notifications from them in my own projects.

    [-]
    • trollbridge 1 hour ago
      Making a strcpy honeypot doesn’t sound like a bad idea…

        void nobody_calls_me(const char *stuff) {
          char *a, *b;
          const size_t c = 1024;

          a = calloc(c);
          if (!a) return;
          b = malloc(c);
          if (!b) {
                  free(a);
                  return;
          }
          strncpy(a, stuff, c - 1);
          strcpy(b, a);
          strcpy(a, b);
          free(a);
          free(b);
  }
      Some clever obfuscation would make this even more effective.
    • Y_Y 1 hour ago
      Because humans generate and relay the slop-reports in the hopes of being helpful
      [-]
      • captn3m0 1 hour ago
        s/being helpful/making money.
  • senthil_rajasek 2 hours ago
    Title is :

    No strcpy either

    @dang

    [-]
    • Snild 1 hour ago
      I don't see a problem with that, but for the record, the title on the site is lower-case for me (both browser tab title, and the header when in reader mode).
      [-]
      • 1f60c 55 minutes ago
        I think the submission originally had a typo ("strpy", with no C)
        [-]