All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Gore, Tim" <tim.gore@intel.com>,
	"Lespiau, Damien" <damien.lespiau@intel.com>,
	"Morton, Derek J" <derek.j.morton@intel.com>
Cc: "intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"Wood, Thomas" <thomas.wood@intel.com>
Subject: Re: [PATCH i-g-t] libs/igt_core.c: Fix compile warnings in igt_core.c
Date: Wed, 20 May 2015 14:14:26 +0300	[thread overview]
Message-ID: <87a8wzjyb1.fsf@intel.com> (raw)
In-Reply-To: <8FCC70911F3E9548866CA0E51893BCC31A35A383@irsmsx105.ger.corp.intel.com>

On Wed, 20 May 2015, "Gore, Tim" <tim.gore@intel.com> wrote:
>> -----Original Message-----
>> From: Lespiau, Damien
>> Sent: Wednesday, May 20, 2015 10:48 AM
>> To: Morton, Derek J
>> Cc: Daniel Vetter; Gore, Tim; intel-gfx@lists.freedesktop.org; Wood, Thomas
>> Subject: Re: [Intel-gfx] [PATCH i-g-t] libs/igt_core.c: Fix compile warnings in
>> igt_core.c
>> 
>> On Wed, May 20, 2015 at 08:37:56AM +0000, Morton, Derek J wrote:
>> >
>> > >> > -----Original Message-----
>> > >> > From: Morton, Derek J
>> > >> > Sent: Tuesday, May 19, 2015 12:21 PM
>> > >> > To: intel-gfx@lists.freedesktop.org
>> > >> > Cc: Wood, Thomas; Gore, Tim; Morton, Derek J
>> > >> > Subject: [PATCH i-g-t] libs/igt_core.c: Fix compile warnings in
>> > >> > igt_core.c
>> > >> >
>> > >> > Fixed variables incorrectly declared as signed instead of unsigned.
>> > >
>> > >Which kind of compiler warning is this? Imo
>> > >
>> > >	for (unsigned int i = 0; i < something; i++)
>> > >
>> > >is just not C style, the int there is perfectly fine. We've had this
>> > >problem before with Android going ridiculously overboard with
>> > >>compiler warnings, and the solution back then was to remove all the
>> > >>silly ones for igt. It smells like the same is appropriate for this
>> > >>>one here too.
>> > >
>> >
>> > The warning occurs because 'something' is of an unsigned type. In this
>> > case the macro ARRAY_SIZE uses sizeof() which returns an unsigned
>> > type. Implicit conversion between signed and unsigned types has always
>> > resulted in compiler warnings in my experience. It is not something
>> > android specific.
>> 
>> unsigned int like that is C99 and the sizeof operator is a size_t, so maybe use
>> that instead of unsigned int?
>> 
>> >
>> > >> > Fixed 'unused parameter' warning from signal handlers that were
>> > >> > not using the signal parameter.
>> > >
>> > >Yeah unused variable because you compile out assert isn't good, it
>> > >will at least break a bunch of library unit tests (the ones in
>> > >>lib/tests). I guess you don't run them in your Android builds?
>> > >>-Daniel
>> >
>> > I have no idea why the asserts are compiled out for android. Tim had
>> > some suggestions which need investigating. A subject for another patch
>> > I guess.  We do not run the unit tests on android because it has not
>> > been possible to run them since they were moved to libs/test. The
>> > android make file was never updated when they were moved.  I need to
>> > look at look at writing a new unit test for the fatal_signal_handler
>> > so will look at getting them to build for android at the same time.
>> >
>> > As the unused parameter changes are more controversial I will remove
>> > them for now and update the patch to just fix the signed / unsigned
>> > warnings.
>> 
>> FWIW, I'd used the gcc unused attribute for things like that instead of those
>> void expressions.
>> 
>> #define __unused __attribute__((unused))
>> 
>> void foo(int bar __unused)
>> {
>>   ...
>> }
>> 
>> --
>> Damien
>
> My penny's worth is this. Most of the time assigning between signed and unsigned
> is just due to sloppy coding. We all do it for sure, and I see it everywhere. But it can
> lead to problems and it is very kind of the compiler to warn you. By default GCC only
> warns you in C++, but I think Google must have tweaked their GCC build, I cannot
> see it turned on in our build command. Fixing these is trivial, does not introduce
> extra code and reduces the noise when building for Android. And its even good
> style (unlike this sentence). I agree with Damien that size_t is probably better
> in this case.

Like both Chris and I said in reply to different versions of the patch,
having to use an explicit cast because of the signed->unsigned change is
bad too. Worse, I think.

BR,
Jani.


>  Tim
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2015-05-20 11:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-19 11:21 [PATCH i-g-t] libs/igt_core.c: Fix compile warnings in igt_core.c Derek Morton
2015-05-19 13:35 ` Gore, Tim
2015-05-20  7:12   ` Daniel Vetter
2015-05-20  8:37     ` Morton, Derek J
2015-05-20  9:19       ` Daniel Vetter
2015-05-20  9:48       ` Damien Lespiau
2015-05-20 10:12         ` Gore, Tim
2015-05-20 11:14           ` Jani Nikula [this message]
  -- strict thread matches above, loose matches on Subject: below --
2015-05-19 14:26 Derek Morton
2015-05-20  7:29 ` Jani Nikula

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=87a8wzjyb1.fsf@intel.com \
    --to=jani.nikula@linux.intel.com \
    --cc=damien.lespiau@intel.com \
    --cc=derek.j.morton@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=thomas.wood@intel.com \
    --cc=tim.gore@intel.com \
    /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.