Re: [PATCH 3/5] selinux: use consistent pointer types for boolean arrays

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 18 Feb 2022 at 17:01, Paul Moore <paul@xxxxxxxxxxxxxx> wrote:
>
> On Thu, Feb 17, 2022 at 9:21 AM Christian Göttsche
> <cgzones@xxxxxxxxxxxxxx> wrote:
> >
> > Use a consistent type of unsigned int* for boolean arrays, instead of
> > using implicit casts to and from int*.
> >
> > Reported by sparse:
> >
> >     security/selinux/selinuxfs.c:1481:30: warning: incorrect type in assignment (different signedness)
> >     security/selinux/selinuxfs.c:1481:30:    expected unsigned int *
> >     security/selinux/selinuxfs.c:1481:30:    got int *[addressable] values
> >     security/selinux/selinuxfs.c:1398:48: warning: incorrect type in argument 3 (different signedness)
> >     security/selinux/selinuxfs.c:1398:48:    expected int *values
> >     security/selinux/selinuxfs.c:1398:48:    got unsigned int *bool_pending_values
> >
> > Signed-off-by: Christian Göttsche <cgzones@xxxxxxxxxxxxxx>
> >
> > ---
> > A more invasive change would be to change all boolean arrays to bool*.
>
> I think that might be a worthwhile change, although that can happen at
> a later date.
>
> A quick general comment: please try to stick to 80-char long lines.  I
> realize Linus/checkpatch.pl has started to allow longer lines but I
> would still like SELinux to try and keep to 80-chars or under.
>
> > diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c
> > index 6901dc07680d..7865926962ab 100644
> > --- a/security/selinux/ss/services.c
> > +++ b/security/selinux/ss/services.c
> > @@ -3175,7 +3175,8 @@ int security_get_bool_value(struct selinux_state *state,
> >  static int security_preserve_bools(struct selinux_policy *oldpolicy,
> >                                 struct selinux_policy *newpolicy)
> >  {
> > -       int rc, *bvalues = NULL;
> > +       int rc;
> > +       unsigned int *bvalues = NULL;
>
> Doesn't this cause a type mismatch (unsigned int vs int) when an entry
> from bvalues[] is assigned to cond_bool_datum::state later in the
> security_preserve_bools() function?

Yes, but those variables *should* only hold the values 0 or 1.
But probably it's better to re-spin for 5.19 with all arrays and
cond_bool_datum::state converted to literal bool type.

>
> --
> paul-moore.com




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux