From patchwork Wed Jul 11 22:00:42 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alex Elder X-Patchwork-Id: 1185681 Return-Path: X-Original-To: patchwork-ceph-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 584303FC8F for ; Wed, 11 Jul 2012 22:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030271Ab2GKWAo (ORCPT ); Wed, 11 Jul 2012 18:00:44 -0400 Received: from mail-yw0-f52.google.com ([209.85.213.52]:36249 "EHLO mail-yw0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030192Ab2GKWAo (ORCPT ); Wed, 11 Jul 2012 18:00:44 -0400 Received: by yhpp61 with SMTP id p61so2049112yhp.11 for ; Wed, 11 Jul 2012 15:00:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=acdDZiSMcdIgopY4E6F/4PxQDKQAtKC5CeGfXzD48Jk=; b=R4fycDMsj/rOpvz1qvpxYBplCM1OzRoVg81WDCB04LZOlXyq67MFBhMMKxjZUYERF0 lp+fZr1TZXfj7VbY17cUWK00t0H98LLOwVMN26Sj41kY6pRxq+87e4owC0R+wgz79sMN qVQKJG2vYPbCHC4jSvFmPi6ux07yis/PMGAWO5OR/YMPmM1Tw05AU9InSHocGf2v52RO 6uXW6VT40kWhzk9HH9vxCPp/zhgdiGphfKHgJpIYi/JDnObpTB65s0ZaxQjJmWte98/U Lw5Qm3IDHUGv8ViwzfMHT6nqZDVv8g7Xtn1SsAE0bbczr5Gr48QqN7a9fFdBqaL5FQU/ 2kCQ== Received: by 10.236.78.1 with SMTP id f1mr60995467yhe.109.1342044043853; Wed, 11 Jul 2012 15:00:43 -0700 (PDT) Received: from [172.22.22.4] (c-71-195-31-37.hsd1.mn.comcast.net. [71.195.31.37]) by mx.google.com with ESMTPS id h15sm2846055ank.1.2012.07.11.15.00.42 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 15:00:43 -0700 (PDT) Message-ID: <4FFDF78A.7050606@inktank.com> Date: Wed, 11 Jul 2012 17:00:42 -0500 From: Alex Elder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: ceph-devel@vger.kernel.org Subject: [PATCH] libceph: re-phrase ceph_decode_need() X-Gm-Message-State: ALoCoQl2+9e6VIIwbAgR7bEXKO70XWvSjU/eOllMwA7sUfdPFevh3Rkz66q/03WQ+ERkKn9gJE/X Sender: ceph-devel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: ceph-devel@vger.kernel.org For some reason, the way ceph_decode_need() is written throws me off whenever I look at it: if (!likely(ceph_has_room(p, end, n))) I read it as "not likely ceph has room," which is not what it really means. Despite being a double-negative, which I normally avoid, I like this better: if (unlikely(!ceph_has_room(p, end, n))) What do you think? Signed-off-by: Alex Elder --- include/linux/ceph/decode.h | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: b/include/linux/ceph/decode.h =================================================================== --- a/include/linux/ceph/decode.h +++ b/include/linux/ceph/decode.h @@ -51,10 +51,10 @@ static inline int ceph_has_room(void **p return end >= *p && n <= end - *p; } -#define ceph_decode_need(p, end, n, bad) \ - do { \ - if (!likely(ceph_has_room(p, end, n))) \ - goto bad; \ +#define ceph_decode_need(p, end, n, bad) \ + do { \ + if (unlikely(!ceph_has_room(p, end, n))) \ + goto bad; \ } while (0) #define ceph_decode_64_safe(p, end, v, bad) \