I'm not a fan of strlcpy(3)

Role and Purpose of strlcpy

• Many see strlcpy as a pragmatic, safer drop‑in than strcpy/strncpy: it bounds writes and turns crashes/exploits into mere truncation bugs.
• Defenders stress: it’s not meant to “fix” all string bugs, just to prevent overflows in legacy C code without massive rewrites.
• Critics argue the interface is still flawed: it encourages naive truncation, has non‑obvious behavior, and isn’t truly a drop‑in for strncpy (different return type, different guarantees about filling the buffer).

Alternatives and Competing APIs

• Several commenters prefer memcpy/memccpy plus explicit '\0', or Linux’s strscpy, claiming they’re clearer and more efficient.
• Others lean on snprintf/asprintf and pointer+length patterns instead of any str*cpy.
• There is concern that adding endless str?cpy variants is “whack‑a‑mole” and each carries its own traps.

C Strings, Safety, and Better Abstractions

• Broad agreement that C’s null‑terminated strings and standard string.h are fundamentally dangerous and archaic.
• Many advocate length‑prefixed or slice types (pointer+size), akin to C++ string_view, Rust &str, or Go slices.
• Some note that C as a language is expressive enough for a good string library; the problem is historical APIs and ecosystem inertia.
• Others argue C is best reserved for low‑level/runtime implementation, not string‑heavy, internationalized apps.

Truncation, Unicode, and User‑Facing Text

• Multiple comments point out that most “safe copy” examples are implicitly ASCII‑only and ignore UTF‑8, code points, and grapheme clusters.
• Byte‑level truncation can break UTF‑8, cause replacement glyphs or decoder failures, and change semantics (e.g., emojis, complex scripts).
• Several argue truncation rules belong in the presentation layer, using locale‑aware algorithms, not in low‑level copying.

Fixed Limits vs Inclusivity (Names, URLs, etc.)

• A long subthread debates fixed buffer limits: “no surname needs 128+ bytes” vs. extensive counterexamples (multi‑component, non‑Latin, very long names; long URLs with hashes).
• One camp prioritizes performance, simplicity, and hard limits; another stresses global inclusivity and warns against “falsehoods programmers believe about names.”
• Consensus: every system must pick some limit, but what’s “reasonable” is context‑dependent and easy to underestimate.

API Design, Naming, and Documentation

• Complaints about cryptic, short C function names and subtle semantic differences (strncpy vs strlcpy vs strscpy).
• Some defend the old style (historical linker limits, expectation that programmers read manpages); others find it a constant source of errors.
• There is frustration that POSIX/C standardization keeps cementing problematic interfaces instead of mandating modern, bounds‑aware string types.