[CRIU] [PATCH 1/8] util: Add read_string helper
Pavel Emelyanov
xemul at parallels.com
Thu May 10 06:17:58 EDT 2012
On 05/10/2012 11:21 AM, Cyrill Gorcunov wrote:
> On Thu, May 10, 2012 at 11:04:52AM +0400, Andrew Vagin wrote:
>> On Sat, May 05, 2012 at 07:20:17PM +0400, Cyrill Gorcunov wrote:
>>>
>>> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
>>> ---
>>> include/util.h | 7 +++++++
>>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>>
>>
>>> diff --git a/include/util.h b/include/util.h
>>> index 5172a88..62e3877 100644
>>> --- a/include/util.h
>>> +++ b/include/util.h
>>> @@ -132,6 +132,13 @@ static inline int read_img_buf(int fd, void *ptr, int size)
>>> #define memzero_p(p) memset(p, 0, sizeof(*p))
>>> #define memzero(p, size) memset(p, 0, size)
>>>
>>> +static inline int read_string(int fd, char *ptr, int size)
>>> +{
>>> + int ret = read(fd, ptr, size);
>>> + ptr[ret > 0 ? ret - 1 : 0] = '\0';
>
>> I don't like it, the last symbol may be non-zero, but we set it to zero,
>> it may hide a problem.
>
> This is done by design. Sure we can return -ENOMEM in case if string
> is trimmed, still it must be guaranted that returned result _is_
> as C-string as function implies.
>
>> if (ret < 0)
>> return ret;
>> else if (ret == size) {
>> if (ptr[ret - 1] != '\0')
>> return -ENOMEM;
>> return ret;
>> } else
>> ptr[ret] = '\0';
>>
>> Why can you not use my decision for similar cases?
>
> I don't like the idea of introducing global variables, this
You can declare Andrey's buffers locally.
> kills ability to use functions in parallel execution. Another
> misdesign I think is that instead of implementing safe-string-read
> in a function itself we introduce 2 requirements
>
> - a _speacially_ configured buffer must be passed
Exactly.
> - a reader must take into account that buffer has zero byte
> at the end
It's always OK.
Andrey's buffers are cool, because you can use them with any stream reading
function (read, fgets, whatever else). Your approach requires writing a helper
for each.
> this looks like overdone for me.
>
>> I think we should have one method for one type of problems.
>> I agree with both of them, so you should chage it everywhere.
>
> Cyrill
> .
>
More information about the CRIU
mailing list