[openib-general] Re: [PATCH] sdp conditional code cleanup
Libor Michalek
libor at topspin.com
Mon Feb 28 13:13:45 PST 2005
On Sun, Feb 27, 2005 at 12:44:41PM +0200, Michael S. Tsirkin wrote:
> Quoting r. Libor Michalek <libor at topspin.com>:
> > On Thu, Feb 24, 2005 at 11:49:28PM +0200, Michael S. Tsirkin wrote:
> > > OK, now what about things like these:
> > >
> > > if (0 > result) {
> > >
> > > may I change them all to
> > >
> > > if (result < 0) {
> > >
> > > While being equivalent, we are testing the result, not 0.
> > >
> > > Similiarly (although I feel somewhat less strongly about it)
> > >
> > > if (0 == result)
> > > and
> > > if (NULL == conn)
> > >
> > > are better off as
> > >
> > > if (!result) {
> > > and
> > > if (!conn)
> > >
> > > C is a Spartan language, and this is more brief.
> > > Libor, I think I asked about the second one, but dont recall you
> > > answering.
> > > If OK to both, let me know and I'll do it on Sunday.
> >
> > I actually feel more strongly in favour of making the second change
> > you propose then the first. However, I'm OK with both, so feel free
> > to submit a patch.
>
> Here is the patch.
>
> I generalized the approach -
> any if (CONSTANT == variable) and if ( CONSTANT & variable) is now
> if (variable == CONSTANT) and if ( variable & CONSTANT)
> and so forth.
>
> Further, some places had weird flag testing code like this:
> if ( (variable & CONSTANT) > 0 )
>
> I changed them all to
>
> if (variable & CONSTANT)
>
> Two things I noticed but did not fix:
>
> A. In some places a positive error code is returned. For example
> ENOBUF and not -ENOBUF. I assume its a bug but did not touch it.
I'm glad you did not change this, it's not a bug. In parts of both
the send and recv data paths positive and negative returns have different
meaning. negative return is a hard error, while positive return is used
to indicate that the data path is in a flow control situation and that
the action will need to be retried later. Zero as usual means success.
> Looks like a lot of changes, I went over them several times and
> everything looks in order to me. I really hope its applied before
> any other change, it almost surely will conflict with any other
> patch, and it'll be a lot of work to re-diff.
I found a few problem spots that I fixed up, before commiting
the code. The third problem was in an #if 0, so it wasn't an
immediate issue. Thanks.
-Libor
@@ -1302,7 +1301,7 @@ static int _sdp_inet_shutdown(struct soc
* 1 - send shutdown
* 2 - send/recv shutdown.
*/
- if (0 > flag || 2 < flag)
+ if (flag < 0 || flag < 2)
return -EINVAL;
@@ -787,7 +787,7 @@ void sdp_iocb_q_cancel(struct sdpc_iocb_
counter < total; counter++) {
next = iocb->next;
- if (0 < (mask & iocb->flags) || SDP_IOCB_F_ALL == mask) {
+ if ((mask & iocb->flags) || msk == SDP_IOCB_F_ALL) {
sdp_dbg_err("IOCB <%d> cancel <%Zu> flag <%04x> "
"size <%Zu:%d:%d>",
iocb->key, comp, iocb->flags, iocb->size,
@@ -1092,35 +1092,35 @@ static int _sdp_inet_recv_urg(struct soc
conn = SDP_GET_CONN(sk);
- if (sock_flag(sk, SOCK_URGINLINE) || 0 == conn->rcv_urg_cnt)
+ if (sock_flag(sk, SOCK_URGINLINE) || !conn->rcv_urg_cnt)
return -EINVAL;
/*
* don't cosume data on PEEK, but do consume data on TRUNC
*/
#if 0
- value = (0 < (MSG_PEEK & flags)) || (0 == size) ? 0 : 1;
+ value = (MSG_PEEK & flags) || size ? 1 : 0;
#else
- value = (0 < (MSG_PEEK & flags)) ? 0 : 1;
+ value = (MSG_PEEK & flags) ? 0 : 1;
#endif
More information about the general
mailing list