[Intel-gfx] [PATCH i-g-t 1/4] kms_content_protection: Fix log bug on 32-bit platforms.

[Ville Syrjälä]

On Thu, Nov 15, 2018 at 10:51:51AM -0800, Eric Anholt wrote:
> Ville Syrjälä <ville.syrjala at linux.intel.com> writes:
> 
> > On Wed, Nov 14, 2018 at 02:28:29PM -0800, Eric Anholt wrote:
> >> long is different between 32 and 64 and should basically never be
> >> used.  Fixes compiler warning about passing the wrong type.
> >> 
> >> Signed-off-by: Eric Anholt <eric at anholt.net>
> >> ---
> >>  tests/kms_content_protection.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> 
> >> diff --git a/tests/kms_content_protection.c b/tests/kms_content_protection.c
> >> index 801eff66c272..bb9ecd3f4cde 100644
> >> --- a/tests/kms_content_protection.c
> >> +++ b/tests/kms_content_protection.c
> >> @@ -89,7 +89,8 @@ wait_for_prop_value(igt_output_t *output, uint64_t expected,
> >>  			return true;
> >>  		usleep(1000);
> >>  	}
> >> -	igt_info("prop_value mismatch %ld != %ld\n", val, expected);
> >> +	igt_info("prop_value mismatch %lld != %lld\n",
> >> +		 (long long)val, (long long)expected);
> >
> > We use the ugly PRId64 & co. elsewhere for this.
> 
> My experience with those ugly macros is that people have a flinch when
> trying to remember how they work and just ignore the issue instead,
> leaving it for those that have to compile for 32.  I'll switch it,
> though.
> 
> Hopefully i-g-t will get cross-compiling CI and merge requests at some
> point so that these bugs can just never land in the first place.

I thought we already did 32bit builds. Hmm. I guess we enabled that
only for the kernel builds.

-- 
Ville Syrjälä
Intel