A NOTE has been added to this issue. ====================================================================== https://www.austingroupbugs.net/view.php?id=1591 ====================================================================== Reported By: eggert Assigned To: ====================================================================== Project: Issue 8 drafts Issue ID: 1591 Category: System Interfaces Type: Error Severity: Objection Priority: normal Status: New Name: Paul Eggert Organization: UCLA User Reference: Section: no section number yet (no draft yet) Page Number: no page number yet (no draft yet) Line Number: no line number yet (no draft yet) Final Accepted Text: ====================================================================== Date Submitted: 2022-06-29 18:39 UTC Last Modified: 2022-06-30 01:12 UTC ====================================================================== Summary: Proposed strlcpy spec has problems ======================================================================
---------------------------------------------------------------------- (0005872) wahern (reporter) - 2022-06-30 01:12 https://www.austingroupbugs.net/view.php?id=1591#c5872 ---------------------------------------------------------------------- > * To address the denial-of-service problem, drop the requirement that strlcpy must compute the string length of an overlong source. If SRC is too long, allow strlcpy(DST, SRC, sizeof DST) to return any value greater than or equal to sizeof DST. This will support the vast majority of uses of strlcpy, which do not need or use the string length. The behavior of returning the logical length is the same or similar to several other POSIX functions, including snprintf and regerror. In fact, OpenBSD's regerror implementation uses strlcpy to provide the POSIX-required regerror return value semantics. It's not uncommon to use the returned logical length to resize a buffer appropriately--e.g. to call regerror once, and upon truncation realloc a buffer and call it again.[1] So simply surveying the immediate sites where strlcpy is used is not going to capture real-world dependencies. Changing this semantic sabotages the purpose of standardizing strlcpy. Most of your objections seem like general gripes with C strings in general. They may be legitimate enough, but strike me as irrelevant. Ditto wrt AddressSanitizer and FORTIFY_SOURCE, which aren't even standardized and are largely platform dependent. [1] If subsequent calls are not idempotent, e.g. because the locale has been changed, then hopefully the caller is using a loop, but in any event idempotency is often expected, rightly or wrongly. There are potential pitfalls like this all over the place. (POSIX says changing locale between regcomp and regexec is undefined, but is silent wrt regerror.) Objections to strlcpy have always struck me as making perfect the enemy of the good. All of this hand-wringing would be better spent on the C committee advocating for proposals that improve and extend variably modified array types. Some of these proposals come close to effectively specifying dependent typing semantics between pointer and size parameters and even struct members. This would be much better--easier, more consistent, more reliable--than the __builtin_object_size hacks FORTIFY_SOURCE rely upon. Issue History Date Modified Username Field Change ====================================================================== 2022-06-29 18:39 eggert New Issue 2022-06-29 18:39 eggert Name => Paul Eggert 2022-06-29 18:39 eggert Organization => UCLA 2022-06-29 18:39 eggert Section => no section number yet (no draft yet) 2022-06-29 18:39 eggert Page Number => no page number yet (no draft yet) 2022-06-29 18:39 eggert Line Number => no line number yet (no draft yet) 2022-06-30 01:12 wahern Note Added: 0005872 ======================================================================
