On Wed, 9 Oct 2024, Alejandro Colomar wrote: > I'm not fabricating, BTW. Here's a list of off-by-one bugs in login > code, precisely due to this size-length naming issue: > <https://github.com/shadow-maint/shadow/commit/6551709e96b2bc6f084fdf170ad5bcc11f0038ab> > <https://github.com/shadow-maint/shadow/commit/15882a5f904b3c277d73254a6953c1051db55df4>
Those don't look to me like they're much to do with size/length *naming* confusion. It's a conceptual confusion about whether the value needed by a particular API includes a null terminator or not, not about what you call size and what you call length. As such, a name without "length" wouldn't help, because if you say countof, there would still be the same confusion about whether the bytes you are counting are meant to include a null terminator or not. You could maybe avoid some cases of such off-by-one errors by language features that tie an array length more closely to a pointer (such as .IDENTIFIER proposals where IDENTIFIER is required to be const size_t, in cases where a pointer-to-VLA is passed, if there were appropriate constraints to require a matching pair of const size_t object and pointer to [.IDENTIFIER] VLA to be passed from caller to callee - more general versions with such strict requirements about passing matching pairs would be less likely to ensure correct sizes everywhere, and this idea about ensuring matching pairs isn't in N3188, it's an idea combining things from multiple papers). But I think naming is essentially orthogonal to any kind of language feature that might enable reliable bounded pointers. -- Joseph S. Myers josmy...@redhat.com
