All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Jeremy Sowden <jeremy@azazel.net>
Cc: devel@driverdev.osuosl.org, maxime.ripard@bootlin.com,
	gregkh@linuxfoundation.org, wens@csie.org,
	Nishka Dasgupta <nishkadg.linux@gmail.com>,
	mchehab@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-media@vger.kernel.org
Subject: Re: [PATCH v2] staging: media: sunxi: Add bool cast to value
Date: Mon, 22 Jul 2019 14:24:38 +0200	[thread overview]
Message-ID: <20190722122438.GA1908@aptenodytes> (raw)
In-Reply-To: <20190722111225.GA2695@azazel.net>

Hi,

On Mon 22 Jul 19, 12:12, Jeremy Sowden wrote:
> On 2019-07-22, at 11:36:51 +0530, Nishka Dasgupta wrote:
> > Typecast as bool the return value of cedrus_find_format in
> > cedrus_check_format as the return value of cedrus_check_format is
> > always treated like a boolean value.
> >
> > Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> > ---
> > Changes in v2:
> > - Add !! to the returned pointer to ensure that the return value is
> >   always either true or false, and never a non-zero value other than
> >   true.
> >
> >  drivers/staging/media/sunxi/cedrus/cedrus_video.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > index e2b530b1a956..b731745f21f8 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -86,7 +86,7 @@ static struct cedrus_format *cedrus_find_format(u32 pixelformat, u32 directions,
> >  static bool cedrus_check_format(u32 pixelformat, u32 directions,
> >  				unsigned int capabilities)
> >  {
> > -	return cedrus_find_format(pixelformat, directions, capabilities);
> > +	return !!(bool)cedrus_find_format(pixelformat, directions, capabilities);
> >  }
> 
> I think the original was fine.  The return value of cedrus_find_format
> will be automatically converted to bool before being returned from
> cedrus_check_format since that is the return-type of the function, and
> the result of converting any non-zero value to bool is 1.

Okay I was a bit unsure about that and wanted to play it on the safe side
without really looking it up, but that gave me the occasion to verify.

From what I could find (from my GNU system's /usr/include/unistring/stdbool.h):

   Limitations of this substitute, when used in a C89 environment:

       - In C99, casts and automatic conversions to '_Bool' or 'bool' are
         performed in such a way that every nonzero value gets converted
         to 'true', and zero gets converted to 'false'.  This doesn't work
         with this substitute.  With this substitute, only the values 0 and 1
         give the expected result when converted to _Bool' or 'bool'.

So since the kernel is built for C89 (unless I'm mistaken), I don't think the
compiler provides any guarantee about bool values being converted to 1 when
they are non-zero. As a result, I think it's best to be careful.

However, I'm not sure I really see what cocinelle was unhappy about. You
mentionned single-line functions, but I don't see how that can be a problem.

So in the end, I think we should keep the !! and drop the (bool) cast if there's
no particular warning about it.

What do you think?

Cheers,

Paul

> >  static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
> > --
> > 2.19.1

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
To: Jeremy Sowden <jeremy@azazel.net>
Cc: Nishka Dasgupta <nishkadg.linux@gmail.com>,
	maxime.ripard@bootlin.com, mchehab@kernel.org,
	gregkh@linuxfoundation.org, wens@csie.org,
	linux-media@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] staging: media: sunxi: Add bool cast to value
Date: Mon, 22 Jul 2019 14:24:38 +0200	[thread overview]
Message-ID: <20190722122438.GA1908@aptenodytes> (raw)
In-Reply-To: <20190722111225.GA2695@azazel.net>

Hi,

On Mon 22 Jul 19, 12:12, Jeremy Sowden wrote:
> On 2019-07-22, at 11:36:51 +0530, Nishka Dasgupta wrote:
> > Typecast as bool the return value of cedrus_find_format in
> > cedrus_check_format as the return value of cedrus_check_format is
> > always treated like a boolean value.
> >
> > Signed-off-by: Nishka Dasgupta <nishkadg.linux@gmail.com>
> > ---
> > Changes in v2:
> > - Add !! to the returned pointer to ensure that the return value is
> >   always either true or false, and never a non-zero value other than
> >   true.
> >
> >  drivers/staging/media/sunxi/cedrus/cedrus_video.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > index e2b530b1a956..b731745f21f8 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> > @@ -86,7 +86,7 @@ static struct cedrus_format *cedrus_find_format(u32 pixelformat, u32 directions,
> >  static bool cedrus_check_format(u32 pixelformat, u32 directions,
> >  				unsigned int capabilities)
> >  {
> > -	return cedrus_find_format(pixelformat, directions, capabilities);
> > +	return !!(bool)cedrus_find_format(pixelformat, directions, capabilities);
> >  }
> 
> I think the original was fine.  The return value of cedrus_find_format
> will be automatically converted to bool before being returned from
> cedrus_check_format since that is the return-type of the function, and
> the result of converting any non-zero value to bool is 1.

Okay I was a bit unsure about that and wanted to play it on the safe side
without really looking it up, but that gave me the occasion to verify.

From what I could find (from my GNU system's /usr/include/unistring/stdbool.h):

   Limitations of this substitute, when used in a C89 environment:

       - In C99, casts and automatic conversions to '_Bool' or 'bool' are
         performed in such a way that every nonzero value gets converted
         to 'true', and zero gets converted to 'false'.  This doesn't work
         with this substitute.  With this substitute, only the values 0 and 1
         give the expected result when converted to _Bool' or 'bool'.

So since the kernel is built for C89 (unless I'm mistaken), I don't think the
compiler provides any guarantee about bool values being converted to 1 when
they are non-zero. As a result, I think it's best to be careful.

However, I'm not sure I really see what cocinelle was unhappy about. You
mentionned single-line functions, but I don't see how that can be a problem.

So in the end, I think we should keep the !! and drop the (bool) cast if there's
no particular warning about it.

What do you think?

Cheers,

Paul

> >  static void cedrus_prepare_format(struct v4l2_pix_format *pix_fmt)
> > --
> > 2.19.1

-- 
Paul Kocialkowski, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com

  reply	other threads:[~2019-07-22 12:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-22  6:06 [PATCH v2] staging: media: sunxi: Add bool cast to value Nishka Dasgupta
2019-07-22  6:06 ` Nishka Dasgupta
2019-07-22 11:12 ` Jeremy Sowden
2019-07-22 11:12   ` Jeremy Sowden
2019-07-22 12:24   ` Paul Kocialkowski [this message]
2019-07-22 12:24     ` Paul Kocialkowski
2019-07-22 13:19     ` Jeremy Sowden
2019-07-22 13:19       ` Jeremy Sowden
2019-07-22 13:44     ` Nishka Dasgupta
2019-07-22 13:44       ` Nishka Dasgupta
2019-07-22 15:05       ` Paul Kocialkowski
2019-07-22 15:05         ` Paul Kocialkowski
2019-07-22 15:58       ` Sakari Ailus
2019-07-22 15:58         ` Sakari Ailus
2019-07-23  7:16         ` Paul Kocialkowski
2019-07-23  7:16           ` Paul Kocialkowski
2019-07-25 11:24 ` Hans Verkuil
2019-07-25 11:24   ` Hans Verkuil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190722122438.GA1908@aptenodytes \
    --to=paul.kocialkowski@bootlin.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeremy@azazel.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-media@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=mchehab@kernel.org \
    --cc=nishkadg.linux@gmail.com \
    --cc=wens@csie.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.