From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D57D2C432BE for ; Thu, 26 Aug 2021 09:04:55 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 707EE610A4 for ; Thu, 26 Aug 2021 09:04:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 707EE610A4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=vt.edu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94.2) (envelope-from ) id 1mJBJP-00017D-Dp; Thu, 26 Aug 2021 05:04:39 -0400 Received: from mail-qk1-x72a.google.com ([2607:f8b0:4864:20::72a]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1mJBJM-000171-Tg for kernelnewbies@kernelnewbies.org; Thu, 26 Aug 2021 05:04:37 -0400 Received: by mail-qk1-x72a.google.com with SMTP id c10so2491039qko.11 for ; Thu, 26 Aug 2021 02:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vt-edu.20150623.gappssmtp.com; s=20150623; h=sender:from:to:cc:subject:in-reply-to:references:mime-version :content-transfer-encoding:date:message-id; bh=Fdc/oWMLxBDBm+T3SUBhTDVUcxR1AjfMGTcba0iZZnw=; b=xi2OIUBeb5+ZEAEXAHtPmLTwQO0SAVAkrN1/vMAH5CsvabQ2jcySCid3DVRaFftp94 GLzfwd26mqzmjo2GQ5JgXfdu/k0mqsVWV8v6o3XQlh86PeBhzaEdT7sGt9iamQNEBU0z tmnA1BMdVFbfiEOe6YB98rZtXWiU6Kzb3b2ICQEHCSG55qDGuL34J1FyZtwKSAtCu/yX FrlcELmbv3k+0a1Bmf4b5B/BNBdwPR/y/cvPyTcZdzwcp5h8pY4GbUVIZL6DdAHh0lwU Go9mMlPMsd+0jPXcCv1B5A7JKhATZDfnBiSqFzh3T8XG7T/Ieb+cIJosODPZcWAM1Md4 o6yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:in-reply-to:references :mime-version:content-transfer-encoding:date:message-id; bh=Fdc/oWMLxBDBm+T3SUBhTDVUcxR1AjfMGTcba0iZZnw=; b=cgdCsQ6EkI3LxaR9Jrw3vi4M5Orrdw6GbzfW9U3EtU6cw8aapldTsvJdHD1SlJKa7U fU03767SRucmzeBUVPVPzexGhTAcoWLVsHRv5roDn9HC8Cm1Jbb9s6T+EUzKo6p1fx28 Jsq33z63J+W3g6cYKgMQhqMAtmoqbJBwCRSXWdaL7Xqr+u6CGN7590WPTxdy4GGx+7ZX S7ayzGJgTwX7vVmmS9M8fLVw9ykCiNBw9l0dZEJ5OrgdE4uLaAYP8+3FKAcb59Fz++td D9kY3ZMxy3fL7S52ZjHuAPuvhmSL/Qd0d+IRF/Hy7ha00Rx0zlzMF+gc2uIIxokV/8dU 4C+w== X-Gm-Message-State: AOAM532Faa5/BwBg4ryRkEE5IUcjHqz8IfmsmhVJSX621DAuQkmDhaUN 0LZSB7XQhP02wLp+qYbvzmjZZw== X-Google-Smtp-Source: ABdhPJwtvbhN6H1z/Z3MdNMdUD/1kkZFsPYvhXXsqQLj3X1XNlQn+JBcJU9Xh9+DbgXSnMPxQoJQYw== X-Received: by 2002:a05:620a:254c:: with SMTP id s12mr2670594qko.112.1629968675408; Thu, 26 Aug 2021 02:04:35 -0700 (PDT) Received: from turing-police ([2601:5c0:c380:d61::359]) by smtp.gmail.com with ESMTPSA id w18sm1284489qto.91.2021.08.26.02.04.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Aug 2021 02:04:34 -0700 (PDT) From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Google-Original-From: "Valdis Kl=?utf-8?Q?=c4=93?=tnieks" X-Mailer: exmh version 2.10.0-pre 07/05/2021 with nmh-1.7+dev To: daniel watson Subject: Re: surround complex macros in () In-Reply-To: <20210826052144.GA6234@challenge-bot.com> References: <20210826052144.GA6234@challenge-bot.com> Mime-Version: 1.0 Date: Thu, 26 Aug 2021 05:04:34 -0400 Message-ID: <91363.1629968674@turing-police> Cc: kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1165808693284353304==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============1165808693284353304== Content-Type: multipart/signed; boundary="==_Exmh_1629968673_8510P"; micalg=pgp-sha256; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit --==_Exmh_1629968673_8510P Content-Type: text/plain; charset=us-ascii On Wed, 25 Aug 2021 22:21:44 -0700, daniel watson said: > let me know if this is the right place to ask. > > i recently tried to make a commit adding parentheses around a macro > value. > > https://lore.kernel.org/linux-staging/20210817043038.GA9492@challenge-bot.com/ > > it was rejected as "This is not a real change that is needed." > > at first, i thought this meant that the code would be identical with and > without parentheses surrounding a complex macro's definition, when the > macro is just typecasting an expression. but then i came up with code > where having parens or not changes the meaning of the code. The fact you can contrive an example where it makes a difference doesn't mean that it makes a difference for the patch as submitted. Hint: If your patch to add parentheses was in fact correct and needed as per your with/sans example, it wouldn't have compiled before, and I, or any of a number of people and build farms, would have submitted patches withing 24 to 48 hours. Of course, that's not the only possible situation.... > this is only a compile time difference, and maybe that's the only > possible difference that could be made by the parentheses. Not at all true. #define with(a,b) (a + b) #define sans(a,b) a + b foo = 23*with(a,b); bar = 23*sans(a,b); This stuff ends up mattering when macros start getting nested deep enough. >From the other day when I was chasing a build error and I had to resort to building a .i file to see what the pre-processor was doing to me: (05:33:04 PM) valdis: #define EGADS 1138 /* code violates the principle of least surprise */ (05:33:49 PM) valdis: Consider this code from include/linux/seqlock.h: (05:33:49 PM) valdis: static inline void __seqprop_assert(const seqcount_t *s) (05:33:49 PM) valdis: { (05:33:49 PM) valdis: lockdep_assert_preemption_disabled(); (05:33:49 PM) valdis: } (05:34:10 PM) valdis: Seems reasonable for a static inline, right? (05:35:06 PM) valdis: Well... that lockdep_asser.. is a macro.. that expands to 41,349 characters. Later examination shows 3,089 ( ) pairs, maximum nesting of 12 deep. > how do i rule out the possibility that the code could compile and have a > different value than expected at runtime? Write clean, clear, unobfuscated code. Don't nest macros too deeply. Understand the C casting rules and operator precedence. And hope to $DEITY that you're not debugging code written by somebody who screwed that stuff up, because if they managed to code something that compiles cleanly even when building with W=1 C=1, and still evaluates to something that isn't what was intented, you're probably looking at a very subtle error indeed. See above for a worked example. :) --==_Exmh_1629968673_8510P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Comment: Exmh version 2.9.0 11/07/2018 iQEcBAEBCAAGBQJhJ1khAAoJEI0DS38y7CIc+/sH/j77iVo5Na66LQR2fV2OvM9T +rLX7ed2gscQPnEdU1JnHekgxBm0K2jBMTZe0fT4wBHkkkQfrxbKMMGldumcAt2Z a/gig/qilRywONU6NyzUUTaF9HqLjBWzGaCYbtWabuyWlCfy2G7/D/C8T9JXULli 5lwnwjDLO0RejlmgP+wmXxzHG6aNBZa0KuKsJVe4WbpxIVQGAVUG22yfWghtUE4H 7l4FcLOnQRbgjELMY5fuJv/v9MkaSNTejyfPvskFudp1CAGHs1hnmoyXAf9ocXGu R9S0/6sMMQSQxUPdgK+n8csy+fTPz0CLP8gm9WpdIjAj574u17c8AX+3841bZo4= =bmie -----END PGP SIGNATURE----- --==_Exmh_1629968673_8510P-- --===============1165808693284353304== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============1165808693284353304==--