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

[Alejandro Colomar <alx+linux-hardening@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]

> Date: 2026-10-22 22:38:12+0200
> From: Alejandro Colomar <alx+linux-hardening@kernel.org>
>
> Hi Steven,
> 
> > Date: 2026-10-22 16:20:00-0400
> > From: Steven Rostedt <rostedt@goodmis.org>
> >
> > On Thu, 22 Oct 2026 22:11:27 +0200
> > Alejandro Colomar <alx+linux-hardening@kernel.org> wrote:
> > 
> > > Agree.
> > > 
> > > But still, a better design would do:
> > > 
> > > 	static inline void
> > > 	seq_buf_set_overflow(struct seq_buf *s)
> > > 	{
> > > 		s->p = NULL;
> > > 	}
> > > 
> > > This is way more robust, and also easier to understand.  My head is
> > > boiling when trying to review this patch set for correctness.  That's
> > > not a good sign.
> > 
> > But that loses all data. We still want access to what was written.
> 
> 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;

s/start/buffer/

> 	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 didn't mention it, but I think it's obvious: you can still read the
string by reading 's.buffer'.


Cheers,
Alex

> 
> 
> Cheers,
> Alex
> 
> > 
> > -- Steve
> 
> -- 
> <https://www.alejandro-colomar.es>



-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]