On Thu, Sep 1, 2011 at 7:20 AM, Bob Pearson
<rpear...@systemfabricworks.com> wrote:
> From: bvanass...@acm.org
> > On Sun, Jul 24, 2011 at 9:43 PM, <rpear...@systemfabricworks.com> wrote:
> > > +static struct ib_ah *rxe_create_ah(struct ib_pd *ibpd, struct
> ib_ah_attr
> > *attr)
> > > +{
> > > + int err;
> > > + struct rxe_dev *rxe = to_rdev(ibpd->device);
> > > + struct rxe_pd *pd = to_rpd(ibpd);
> > > + struct rxe_ah *ah;
> > > +
> > > + err = rxe_av_chk_attr(rxe, attr);
> > > + if (err)
> > > + goto err1;
> > > +
> > > + ah = rxe_alloc(&rxe->ah_pool);
> > > + if (!ah) {
> > > + err = -ENOMEM;
> > > + goto err1;
> > > + }
> > > +
> > > + rxe_add_ref(pd);
> > > + ah->pd = pd;
> > > +
> > > + err = rxe_av_from_attr(rxe, attr->port_num, &ah->av, attr);
> > > + if (err)
> > > + goto err2;
> > > +
> > > + return &ah->ibah;
> > > +
> > > +err2:
> > > + rxe_drop_ref(pd);
> > > + rxe_drop_ref(ah);
> > > +err1:
> > > + return ERR_PTR(err);
> > > +}
> >
> > I'm not sure that using a variable with the name "err" and labels with
> > names "err1" and "err2" is a good idea with regard to readability.
>
> There are a lot of these. I used err instead of ret in cases where the only
> purpose of the return was to indicate an error. I used a lot of stacked
> error returns to avoid repetitive cleanup stanzas. Again the name errN:
> implies an error occurred. How about errorN: Is that enough different to
> avoid the confusion you sense?
If you are going to rename the "err<n>" labels, maybe it's a better
idea to rename these into "fail<n>" instead of "error<n>". Maybe it's
even possible to do this renaming with sed.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
