From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3893 invoked by alias); 21 Oct 2002 13:43:06 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 3851 invoked from network); 21 Oct 2002 13:43:04 -0000 Received: from unknown (HELO smtp-relay-2.adobe.com) (192.150.11.2) by sources.redhat.com with SMTP; 21 Oct 2002 13:43:04 -0000 Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g9LDe4Pg021182 for ; Mon, 21 Oct 2002 06:40:04 -0700 (PDT) Received: from iplan-mn.corp.adobe.com (iplan-mn.corp.adobe.com [130.248.25.5]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g9LDeD2b015232 for ; Mon, 21 Oct 2002 06:40:14 -0700 (PDT) Received: from [130.248.25.159] ([153.32.12.150]) by iplan-mn.corp.adobe.com (Netscape Messaging Server 4.15 mn Jul 11 2001 16:32:57) with ESMTP id H4C3FG00.EJZ; Mon, 21 Oct 2002 08:42:52 -0500 User-Agent: Microsoft-Entourage/10.0.0.1331 Date: Mon, 21 Oct 2002 06:43:00 -0000 Subject: Re: Avoiding "assignment from incompatible pointer type" warning From: John Love-Jensen To: Claudio Bley , Florian Weimer CC: Joshua Nye , Steve Dondley , Message-ID: In-Reply-To: <15795.58223.521979.895246@wh2-19.st.uni-magdeburg.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2002-10/txt/msg00241.txt.bz2 Hi Claudio, > I can't see why. Can you elaborate on that? I mean, casting on the > machine code level does just nothing - it's just "syntactic sugar" to > convince the compiler to be quiet. I think casting from one pointer > type to another does no harm at all. Am I wrong? You are correct, the casting is fine, insofar as the given code snippet goes. I assume the complaint/concern was regarding the (presumed) dereferencing of the int* p at some later point in the code. Note: cavalier casting is highly suspect, and prone to be very platform specific (when it does work as intended). For instance, on Solaris a misaligned value can cause a bus error. Often the injudicious, cavalier casting is the culprit. To do the hex dump as intended, I'd do something like this... void HexDump(void* ptr, size_t len) { unsigned char* p = (unsigned char*)ptr; while(len--) { printf("%02x%c", *p++, len ? ' ' : '\n'); } } int main() { float g = 3.141592653589793238; HexDump(&g, sizeof g); } ...but that's just me. :-) --Eljay