No strcpy either

Removal of strcpy in curl

• Commenters applaud the effort to remove strcpy but stress this is only one small step toward memory safety, not a complete solution.
• Some note that simply banning strcpy only makes code “a bit less unsafe”; what matters is what replaces it and how rigorously lengths are tracked.

Design of curlx_strcopy

• Several people are uneasy that the new helper:
  • Takes destination buffer + size and source + length,
  • Silently truncates by writing an empty string when the copy can’t fit,
  • Returns void.
• Critics argue it should:
  • Return an explicit status code,
  • Leave the destination untouched on failure.
• The presence of DEBUGASSERT is seen as a hint that failures are “not supposed to happen”, but commenters worry about release builds where such asserts vanish.

C string APIs and historical baggage

• Long discussion around strcpy/strncpy/strlcpy:
  • strncpy is defended as originally for fixed-width, NUL‑padded fields (e.g., directory entries, on-disk or wire formats), not as a safe strcpy.
  • Its non-guaranteed NUL termination and undefined behavior with overlapping buffers are seen as major footguns when misused as a general-purpose “safe copy”.
  • strlcpy is viewed as an improvement but still problematic: truncation is usually wrong, and it still walks the whole string.
• Many argue C should have come with a standard length-tracking string type or slice-like struct; today each project reinvents its own.

Null-terminated strings, safety, and performance

• Several advocate moving away from NUL-terminated strings where possible, even in C, toward “pointer + length” representations.
• Others recount real-world C bugs and the high cost of debugging subtle memory/string issues, contrasting this with languages and type systems (e.g., Rust’s safe subset, borrow checker) that encode aliasing and bounds at the type level.
• Performance-wise, strcpy is criticized as suboptimal on modern CPUs compared to length-based bulk copies.

AI-generated “slop” vulnerability reports

• Strong frustration with AI-driven, low-effort bug bounty reports:
  • strcpy in code is described as a “honeypot” for hallucinated vulnerabilities with convoluted but incorrect proofs.
  • Maintainers must spend time refuting these claims despite no bounties being offered.
• Some joke about deliberately adding a strcpy honeypot function to attract and identify such reports.
• Distinction is made between these sloppy AI-assisted reports and high-quality automated analyzers, which have genuinely helped fix many defects.