From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44099 invoked by alias); 8 Jan 2016 23:51:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 44068 invoked by uid 89); 8 Jan 2016 23:51:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1949, claim, bitfields X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 08 Jan 2016 23:51:17 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1aHgoK-0000Yk-5S from joseph_myers@mentor.com ; Fri, 08 Jan 2016 15:51:12 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Fri, 8 Jan 2016 23:51:10 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1aHgoH-00056A-3u; Fri, 08 Jan 2016 23:51:09 +0000 Date: Fri, 08 Jan 2016 23:51:00 -0000 From: Joseph Myers To: Martin Sebor CC: Marek Polacek , GCC Patches Subject: Re: C PATCH to rectify warning for character types (PR c/23087) In-Reply-To: <56904612.800@gmail.com> Message-ID: References: <20160107171127.GK31604@redhat.com> <568FF69B.10803@gmail.com> <56904612.800@gmail.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-01/txt/msg00491.txt.bz2 On Fri, 8 Jan 2016, Martin Sebor wrote: > > Signedness of char (and of bit-fields) is a tristate, "signed", "unsigned" > > and "". My claim is that a difference between any two of those three > > values is essentially the same kind of difference. And so at most the > > wording should be adjusted (or maybe an inform ("% and % > char%> are different types" added), not the conditions for some such > > warning to be given. > > This explanation isn't grounded in the C definition of the types > (which is fine if you want to use some other definition of > "signedness"). > > In C, plain char type is neither a signed nor an unsigned integer > type, whether or not it has a sign bit. It's a distinct type that's Exactly. "signed type", "unsigned type" and "type that is neither signed nor unsigned" are the three cases in the tristate. ("type that is both signed and unsigned" doesn't exist.) The point of this warning is that there are certain cases of incompatible types that are less serious than others - namely, those where the only aspect of the type that is different is its signedness. Those get a more specific warning, which is given under more restrictive conditions. ISO C specifically envisages such differences as being less serious when it allows variation between pointers to character types and void when passing arguments to unprototyped functions. > However, this definition of signedness would imply that the > warning should not be issued for the code below (for example) > when int and long have the same size, representation, and > alignment: > > int *p = (long*)0; And of course the signedness warning isn't issued - the other generic warning about incompatible types is issued, because this is one of the more serious cases of incompatibility, where there is a difference other than signedness. -- Joseph S. Myers joseph@codesourcery.com