Re: [PATCH v4 05/11] seq_buf: Add seq_buf_strlen()

On Sat, Oct 03, 2026 at 06:36:49PM +0300, Andy Shevchenko wrote:

On Fri, Oct 02, 2026 at 08:59:10PM -0700, Kees Cook wrote:

quoted

Several strlcat() call sites being converted to seq_buf need behavior
seq_buf doesn't currently provide. The return from seq_buf_used() is
not the length of the string in a seq_buf. Once the buffer is full or
has overflowed it returns the buffer size, which counts the byte that
seq_buf_str() replaces with the NUL, so a caller that needs the string
and its length has to call seq_buf_str() and then walk the string with
strlen().

Move the termination out of seq_buf_str() into a helper that returns
where it put the NUL, and add seq_buf_strlen(), which terminates the
buffer in the same way and returns that offset.

As discussed in review, don't add WARN_ON() for seq_buf_strlen() and
drop it from seq_buf_str().

Add tests comparing seq_buf_strlen() against strlen() of seq_buf_str()
for empty, appended, truncated, exactly full, and overflowed buffers,
checking that seq_buf_strlen() alone terminates a full buffer, and
checking that a zero-sized seq_buf reports an empty string from both
accessors without touching the buffer.

Tests passed under qemu on ARCH=x86_64 with GCC 16.2.0 and CONFIG_KASAN=y,
and on big-endian ARCH=s390 with GCC s390x-linux-gnu 16.2.0.

...

quoted

 static inline const char *seq_buf_str(struct seq_buf *s)
 {
-	if (WARN_ON(s->size == 0))
+	if (s->size == 0)
 		return "";
 
-	if (seq_buf_buffer_left(s))
-		s->buffer[s->len] = 0;
-	else
-		s->buffer[s->size - 1] = 0;
+	__seq_buf_terminate(s);
 
 	return s->buffer;
 }

Looking at this again, can't it be rewritten now using _strlen()?

	if (seq_buf_strlen(s))
		return s->buffer;

	return "";

?

It could, but I'm vaguely nervous about the difference between
	s->buffer[0] == '\0'
and
	.data ""

i.e. we only force the return of seq_buf_str() to be _not_ just
s->buffer when s->buffer is weirdly impossible (due to size == 0).
I'd rather not make all 0-len strings return the .data segment's const
"" string...

-- 
Kees Cook