On Wed, Jul 12, 2023 at 04:19:31PM -0400, Kent Overstreet wrote: > On Wed, Jul 12, 2023 at 12:58:54PM -0700, Kees Cook wrote: > > On Tue, May 09, 2023 at 12:56:54PM -0400, Kent Overstreet wrote: > > > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > > > > > > printbuf now needs to know the number of characters that would have been > > > written if the buffer was too small, like snprintf(); this changes > > > string_get_size() to return the the return value of snprintf(). > > > > Unfortunately, snprintf doesn't return characters written, it return > > what it TRIED to write, and can cause a lot of problems[1]. This patch > > would be fine with me if the snprintf was also replaced by scnprintf, > > which will return the actual string length copied (or 0) *not* including > > the trailing %NUL. > > ...All of which would be solved if we were converting code away from raw > char * buffers to a proper string building type. > > Which I tried to address when I tried to push printbufs upstream, but > that turned into a giant exercise in frustration in dealing with > maintainers. Heh, yeah, I've been trying to aim people at using seq_buf instead of a long series of snprintf/strlcat/etc calls. Where can I look at how you wired this up to seq_buf/printbuf? I had trouble finding it when I looked before. I'd really like to find a way to do it without leaving around foot-guns for future callers of string_get_size(). :) I found the printbuf series: https://lore.kernel.org/lkml/20220808024128.3219082-1-willy@xxxxxxxxxxxxx/ It seems there are some nice improvements in there. It'd be really nice if seq_buf could just grow those changes. Adding a static version of seq_buf_init to be used like you have PRINTBUF_EXTERN would be nice (or even a statically sized initializer). And much of the conversions is just changing types and functions. If we can leave all that alone, things become MUCH easier to review, etc, etc. I'd *love* to see an incremental improvement for seq_buf, especially the heap-allocation part. -- Kees Cook
