[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <533659E2.4010001@t-25.ru>
Date: Sat, 29 Mar 2014 09:28:02 +0400
From: Anton Leontiev <bunder@...5.ru>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
CC: Mauro Carvalho Chehab <m.chehab@...sung.com>,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [media] uvcvideo: Fix marking buffer erroneous in case
of FID toggling
28.03.2014 20:12, Laurent Pinchart пишет:
>>>> + * Set error flag for incomplete buffer.
>>>> + */
>>>> +static void uvc_buffer_check_bytesused(const struct uvc_streaming *const
>>>> stream,
>
> No need for the second const keyword here.
>
> I would have used "uvc_video_" as a prefix, to be in sync with the surrounding
> functions. What would you think of uvc_video_validate_buffer() ?
>
>>>> + struct uvc_buffer *const buf)
>
> And no need for const at all here.
>
>>>> +{
>>>> + if (buf->length != buf->bytesused &&
>>>> + !(stream->cur_format->flags & UVC_FMT_FLAG_COMPRESSED))
>
> The indentation is wrong here, the ! on the second line should be aligned to
> the first 'buf' of the first line.
>
> If you agree with these changes I can perform them while applying, there's no
> need to resubmit the patch.
>
Thank you for reviewing my first patch to Linux kernel. I completely
agree with your changes.
Just want to ask why there is no need for the second 'const' after
pointer character '*'? I thought it marks pointer itself as constant for
type-checking opposite to first 'const', which marks memory it points to
as constant for type-checking. I understand that the function is simple
enough to verify it by hand but it's better to add more information for
automatic checking.
Is there any guidelines on 'const' keyword usage in Linux kernel code?
Regards,
--
Anton Leontiev
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists