From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 106393 invoked by alias); 8 Jan 2016 23:28:30 -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 106370 invoked by uid 89); 8 Jan 2016 23:28:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=classified, distinct, H*RU:209.85.192.65, Hx-spam-relays-external:209.85.192.65 X-HELO: mail-qg0-f65.google.com Received: from mail-qg0-f65.google.com (HELO mail-qg0-f65.google.com) (209.85.192.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 08 Jan 2016 23:28:28 +0000 Received: by mail-qg0-f65.google.com with SMTP id 6so38126403qgy.3 for ; Fri, 08 Jan 2016 15:28:28 -0800 (PST) X-Received: by 10.140.97.202 with SMTP id m68mr1979349qge.102.1452295706500; Fri, 08 Jan 2016 15:28:26 -0800 (PST) Received: from [192.168.0.26] (71-212-229-169.hlrn.qwest.net. [71.212.229.169]) by smtp.gmail.com with ESMTPSA id w10sm49201778qhc.16.2016.01.08.15.28.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Jan 2016 15:28:25 -0800 (PST) Message-ID: <56904612.800@gmail.com> Date: Fri, 08 Jan 2016 23:28:00 -0000 From: Martin Sebor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Joseph Myers CC: Marek Polacek , GCC Patches Subject: Re: C PATCH to rectify warning for character types (PR c/23087) References: <20160107171127.GK31604@redhat.com> <568FF69B.10803@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-01/txt/msg00489.txt.bz2 > 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 incompatible with both signed char and unsigned char, and pointers to the three types are incompatible with one another. The only thing char, signed char, and unsigned char have in common other than the word "char" is that they are classified as "character types." (Plain "char" might as well be called "character.") >> It seems to me that by the interpretation you suggest, converting >> a signed int* to unsigned long* should be controlled by -Wpointer- >> sign when int and long have the same representation, and by >> -Wincompatible-pointer-types otherwise. (Which is not what GCC >> does.) > > No, because those differ between "int" and "long", not between "signed" > and "" or "unsigned" and "" as signedness. int and long differ because they're not compatible according to the C definition of the term, even if they have the same size, representation, and alignment (e.g., in ILP32). "char" and "signed char" are also incompatible, even if they otherwise have identical properties, for the same reason (i.e., because the standard says they're not). I believe the answer here hinges on the definition of the term "signedness." If we use the same definition as the standard, the text of the warning is strictly speaking incorrect, and the proposed change makes it correct. If we define signedness differently, say as "having a sign bit," then the warning is appropriate in one of the two cases in the bug but not in the other. Which one depends on the the setting of -fsigned-char: signed char *ps = "signed"; // okay with -fsigned-char unsigned char *pu = "unsigned"; // okay with -fno-signed-char and ditto for: extern char *p; ps = p; // okay with -fsigned-char pu = p; // okay with -fno-signed-char 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; Perhaps there is another definition according to which the text of the warning would be correct in all cases. If there is one, it should be outlined in the documentation. (I would recommend using the standard definition since that's what most users are either already familiar with or can easily look it up.) Martin