From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92969 invoked by alias); 24 Nov 2017 19:13:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 92955 invoked by uid 89); 24 Nov 2017 19:13:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=H*M:276c X-HELO: mx1.redhat.com Subject: Re: [PATCH] support: Add TEST_COMPARE macro To: Paul Eggert , Siddhesh Poyarekar , GNU C Library Cc: Adhemerval Zanella References: <8d63a2dc-f9e9-acaa-5ac5-ac5c4fbd6c9f@redhat.com> <8c399cde-3093-0195-a89a-ca230540cffb@gotplt.org> <8339a519-935a-019c-4a8f-798e37f6f346@redhat.com> <5c5fbfc4-0077-22ad-1fd4-53388acaf1e7@cs.ucla.edu> <96692ad0-180c-6e7c-79c8-e5c96d79e34c@cs.ucla.edu> From: Florian Weimer Message-ID: <7e965c74-8113-72b9-276c-baa031df007e@redhat.com> Date: Fri, 24 Nov 2017 19:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <96692ad0-180c-6e7c-79c8-e5c96d79e34c@cs.ucla.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-11/txt/msg00889.txt.bz2 On 11/24/2017 07:31 PM, Paul Eggert wrote: > Florian Weimer wrote: >> I expect that GCC will eventually warn about such tautological >> comparisons.  The current approach avoids such warnings. > > I've found such warnings to be more trouble than they're worth, in cases > like these. (Why would we want GCC to warn that it's doing an > optimization? We *like* optimizations! :-) And efforts to suppress such > warnings, such as using "x > 0" instead of "x < 0", typically cause the > compiler to generate worse code. > > If performance is not important here then I suppose it's OK. However, > it's a bad habit and I don't want the habit to leak into code where > performance matters. It's for writing tests. Performance does not matter. And even for the tests, the additional which cannot be optimized away is on the failure path. >>> I don't know what the context for this new macro is, and like Andreas >>> I'm a bit puzzled as to its intended use. >> >> The purpose is to check if two values are the same, and print them >> (and record a test failure) if they are not. > > Why would we want to compare (say) an uintptr_t value with a pid_t > value? That sounds like a typo, and I'd rather see a compile-time > diagnostic for the typo. It should be easy to arrange for such a > diagnostic, and then we won't have to worry about run-time sign checking > or pacifying GCC about comparisons. The POSIX interfaces are not strongly typed. Types like pid_t should have been structs, but compilers and ABIs simply weren't ready for that. More importantly for us right now is that comparisons between actual and expected values often have differing types. Concrete types vary between architectures, and not just their sizes (e.g., 32-bit architectures use longs where 64-bit architectures use int). Considering that the macro tries very hard to avoid bit-altering conversions, the worst you can get is a spurious test failure, so I don't see why this is a problem. (I could perhaps add an assert that the argument types are not floating point types. But we use floating point values so rarely that this didn't occur to me earlier.) Thanks, Florian