From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5919 invoked by alias); 9 Jun 2011 08:16:09 -0000 Received: (qmail 5900 invoked by uid 22791); 9 Jun 2011 08:16:05 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-px0-f176.google.com (HELO mail-px0-f176.google.com) (209.85.212.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 09 Jun 2011 08:15:49 +0000 Received: by pxi11 with SMTP id 11so721598pxi.21 for ; Thu, 09 Jun 2011 01:15:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.17.198 with SMTP id q6mr151791pbd.287.1307607349290; Thu, 09 Jun 2011 01:15:49 -0700 (PDT) Received: by 10.68.47.67 with HTTP; Thu, 9 Jun 2011 01:15:49 -0700 (PDT) Date: Thu, 09 Jun 2011 11:26:00 -0000 Message-ID: Subject: How to avoid "the address of 'foo' will never be NULL" warning inside macros? From: Steffen Dettmer To: gcc-help Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg00204.txt.bz2 Hi, we implement some features either as functions or macros (if small). One of the used compilers is gcc. With gcc-4.6.0 we get new warnings. With macros, we for example have: #define fooGetFooPtr(bar) \ (const uint8*)(((bar) != NULL ? (bar)->foo_ : (const uint8*)bar)) when used as: struct bar_s bar; ptr *p = fooGetFooPtr(&bar); leading to: error: the comparison will always evaluate as 'true' for the address of 'bar' will never be NULL [-Werror=address] Of course, we considering the preprocessor output this is obiously a warning and the check can be omitted, but for the developer it is not because "hidden" inside the macro. The developer shall not need to care whether the used fooGet* function is implemented in form of a C function or a CPP macro (the usage semantics should be equal). What is recommended to do here? - Removing the check from the macro changes behavior when called with a "free" pointer passed from somewhere else, - implementing the macro as function would probably help but may cause overhead and may have additional effects - implementing the macro as function for gcc of gcc-4.6.0 only seems to be ugly and needlessly conditional - disabling the warning would (I guess) also affect when checking addresses without using macros How to address this in a good way? What is recommended? Regards, Steffen