[SSSD] [PATCH v1 1/5] NEW CLIENT: plugin for NFSv4 rpc.idmapd

Sumit Bose sbose at redhat.com
Mon Feb 3 10:37:35 UTC 2014


On Mon, Feb 03, 2014 at 11:25:00AM +0100, Lukas Slebodnik wrote:
> On (03/02/14 10:11), Sumit Bose wrote:
> >On Mon, Feb 03, 2014 at 09:19:49AM +0100, Lukas Slebodnik wrote:
> >> On (02/02/14 11:16), Noam Meltzer wrote:
> >> >> > +    return 0;
> >> >> > +}
> >> >> > +
> >> >> > +static int sss_nfs_princ_to_ids(char *secname, char *princ, uid_t *uid,
> >> >> > +                                gid_t *gid, extra_mapping_params **ex)
> >> >> > +{
> >> >> > +    (void)secname;
> >> >> > +    (void)princ;
> >> >> > +    (void)uid;
> >> >> > +    (void)gid;
> >> >> > +    (void)ex;
> >> >>
> >> >> Why these (void)s ?
> >> >>
> >> >Best practice, IMHO. In case someone decided to enable "
> >> >-Wunused-parameter" in the compile flags.
> >> >(I prefer that over using gcc's __attribute__(unused) )
> >> >
> >> 
> >> +1
> >> 
> >> I have almost ready patches forr sssd to enable -Wunused-parameter
> >> and I also prefer casting to void, but I also add a comment e.g.
> >> 
> >> sss_child_krb5_trace_cb(krb5_context context,
> >>                         const krb5_trace_info *info, void *data)
> >> {
> >>     (void) context; /* unused */
> >>     (void) data; /* unused */
> >
> >I like this, but maybe a macro like MARK_AS_UNUSED or similar would make
> >the purpose more clear and might help to avoid questions like to one
> >above?
> >
> But macro will need to be in separate header file, because we will need to use
> it also in the client code. This is a reason why I prefer to use comment and to
> avoid using macro. But separate header file can be acceptable solution.

There are other examples, e.g. the SAFEALIGN macros, which are used by
client and server code. The there is no existing header file where this
now macro would fit, I'm fine with creating a new one with the special
purpose to hold stuff which is used by client and server code.

bye,
Sumit
> 
> LS
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list