Re: [PATCH v5 06/12] seq_buf: Add seq_buf_strlen()

[Steven Rostedt]

On Thu, 22 Oct 2026 22:38:03 +0200
Alejandro Colomar <alx+linux-hardening@xxxxxxxxxx> wrote:

> No, it doesn't lose data.  My proposal is to have this:
> 
> 	struct my_seq_buf {
> 		// .buffer points to the start of the buffer
> 		char  *buffer;
> 
> 		/* .p points to the current position.  This is the last
> 		 * '\0' that has been written to the buffer.  On
> 		 * truncation, it is a NULL pointer.
> 		 */
> 		char  *p;
> 
> 		/* .end always holds ARRAY_END(buffer).  It is a pointer
> 		 * one-past-the-last character in the buffer.
> 		 */
> 		char  *end;
> 	};
> 
> This would be initialized as (of course, wrapper in static inline
> functions as needed) this:
> 
> 	char            buf[100];
> 	struct seq_buf  b;
> 
> 	b.buffer = buf;
> 	b.p = buf;
> 	b.end = ARRAY_END(buf);
> 
> Then, you would write to it as:
> 
> 	b.p = stpecpy(b.p, b.end, "foo");
> 	b.p = stpecpy(b.p, b.end, "bar");
> 	...
> 	b.p = stpecpy(b.p, b.end, "baz");
> 	if (b.p == NULL)
> 		goto fail;
> 
> Then, at some point, you might want to initialize a new buffer out of
> the remainings of it:
> 
> 	struct seq_buf  b2;
> 
> 	if (b.p == NULL)
> 		goto fail;
> 	b2.start = b.p;
> 	b2.p = b.p;
> 	b2.end = b.end;
> 
> See how simple this becomes?  (So much that you may doubt the necessity
> of the set of APIs at all, but they don't hurt much either.)

I rather not increase its size. It is embedded in the trace_seq.

Yes the seq_buf code can be complex, but it's in one location where it can
be highly tested and verified. The point of seq_buf is to do the complexity
so that other places in the kernel doesn't need to.

-- Steve