lkml.org 
[lkml]   [2023]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] seq_buf: Introduce DECLARE_SEQ_BUF and seq_buf_cstr()
On Thu, 26 Oct 2023 10:07:28 -0700
Kees Cook <keescook@chromium.org> wrote:

> Solve two ergonomic issues with struct seq_buf:

"ergonomic"? Does it cause carpal tunnel? ;-)

>
> 1) Too much boilerplate is required to initialize:
>
> struct seq_buf s;
> char buf[32];
>
> seq_buf_init(s, buf, sizeof(buf));
>
> Instead, we can build this directly on the stack. Provide
> DECLARE_SEQ_BUF() macro to do this:
>
> DECLARE_SEQ_BUF(s, 32);
>
> 2) %NUL termination is fragile and requires 2 steps to get a valid
> C String (and is a layering violation exposing the "internals" of
> seq_buf):
>
> seq_buf_terminate(s);
> do_something(s->buffer);
>
> Instead, we can just return s->buffer direction after terminating it
> in refactored seq_buf_terminate(), now known as seq_buf_cstr():
>
> do_soemthing(seq_buf_cstr(s));

Do we really need to call it _cstr? Why not just have seq_buf_str() ?

I mean, this is C, do we need to state that in the name too?

BTW, I'm perfectly fine with this change, just the naming I have issues
with.

-- Steve

\
 
 \ /
  Last update: 2023-10-26 19:39    [W:0.078 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site