Re: [PATCH 3/5] Add a ckpt_read_string() function to allow reading of a variable-length (but length-capped) string from the checkpoint stream.

[Oren Laadan <orenl-RdfvBDnrOixBDgjK7y7TUQ@public.gmane.org>]

Dan Smith wrote:
> OL> You can avoid the memcpy() if you first read only the header, allocate
> OL> the string, and then read data into it.
> 
> I've changed it to a _ckpt_read_obj_type(.., NULL, ..) and a
> ckpt_kread() to avoid the memcpy().
> 
> OL> On top of this you can have ckpt_read_string() that will verify that
> OL> the buffer is of non-zero length and null terminated ?
> 
> What I had ensured a null-terminated string (kzalloc() and len+1). 

Of course: that's what _ckpt_read_obj_string() does, and why I
suggested ckpt_read_string(), otherwise it's redundant.

> 
> Is this really the appropriate place to ensure that the string is
> non-zero length?  Maybe not in the realm of paths and socket names,
> but I can see other places where writing a zero-length string might be
> appropriate...

I used the term "buffer":  a zero-length string is a buffer of length 1.
A zero-length buffer becomes (e.g. empty pipe buffer) causes no allocation
and returns a NULL pointer. Callers that deal with strings will likely
not expect this behavior.

Thanks,

Oren.