[Intel-gfx] [PATCH] i915/intel_tv_get_modes: fix strncpy truncation warning

[Dominique Martinet]

Ville Syrjälä wrote on Thu, Jul 12, 2018:
> On Wed, Jul 11, 2018 at 09:46:15AM +0200, Dominique Martinet wrote:
> > This is effectively no-op as the next line writes a nul at the final
> 
> What is "This". Please write self contained commit messages.

This could either be 'this commit' as a whole or if you look only at the
commit message 'this strncpy fix' from the title (which is arguably the
same), and both interpretations sound fairly understandable in the
context of the title line without seeing the patch to me... Although
I'll admit this is difficult to judge of that as the author.

Thanksfully, the v2 of the patch didn't use this wording but while I
agree the message could be better I do not think it was horrible.


> > drivers/gpu/drm/i915/intel_tv.c: In function ‘intel_tv_get_modes’:
> > drivers/gpu/drm/i915/intel_tv.c:1358:3: error: ‘strncpy’ specified bound 32 equals destination size [-Werror=stringop-truncation]
> >    strncpy(mode_ptr->name, input->name, DRM_DISPLAY_MODE_LEN);
> >    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> 
> That warning should be in the actual commit message.

Yes and no, I gave it for referrence but when you update to gcc 8 you
will literally see it all over the place.
The words "strncpy truncation warning" is really precise once you've
seen them a few times and there are litteraly hundred of these warnings
in the kernel, some have already been fixed taking a glance at the git
log, some with and without the warning message.
I don't think it's worth polluting the git log with this many
warnings... Which leads to...

> This same pattern is used all over drm. Can you go and fix them all up?
> One might even consider writing a cocci patch for it ;)

Now this is something I can agree with.
This patch really was just a stop-gap measure because I could not build
the kernel at all without it, but yes I did consider having a look at
others.

Unfortunately coccinelle does not run on fedora 28 (and doesn't look
like it will fix itself any time soon, there is a bug report[1] open
since February that didn't get much love lately - I was just looking at
it a few days ago)

I think in this case it might actually be faster to look at gcc warnings
and s/strncpy/strlcpy/, but I am curious about Coccinelle so this is a
good excuse to look at it, I'll report back in a bit after poking at
that bug report and figuring out how coccinelle works.

I do not guarantee speed however, if anyone sees this and feels put off
from donig it themselves, please go ahead and just drop me a word.


[1] https://bugzilla.redhat.com/show_bug.cgi?id=1544204

Thanks, and sorry for the mail longer than I originally intended,
-- 
Dominique Martinet