From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Iy7Ab-0005U6-C6
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:48:45 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Iy7Ab-0005T5-09
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:48:45 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Iy7Aa-0005So-MD
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:48:44 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1Iy7AZ-000511-Rq
	for qemu-devel@nongnu.org; Fri, 30 Nov 2007 09:48:44 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] fix gcc4 compile warnings
Date: Fri, 30 Nov 2007 14:48:38 +0000
References: <474F5223.1000202@andrep.de> <475019BF.4040906@amd.com>
	<fb249edb0711300630j74911cf6lba75c397b9f7c8fe@mail.gmail.com>
In-Reply-To: <fb249edb0711300630j74911cf6lba75c397b9f7c8fe@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200711301448.39882.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> > What solution do you prefer for the opaque types? I have used the simple:
> >  >> -    void *args[MAX_ARGS];
> >  >> +    intptr_t args[MAX_ARGS];
> >
> > A more portable and clean solution would be this:
> > -    void *args[MAX_ARGS];
> > +    union
> > +    {
> > +        void* ptr;
> > +        int i;
> > +    } args[MAX_ARGS];
> > If you prefer this, I can change the patch accordingly.
>
> I'm not sure why you get a warning here and I'm unable to run a build
> at the moment. A void * should be able to store some (unknown size)
> integer regardless of the platform.

Unfortunately there is no portable and reliable solution, other than avoiding 
storing arbitrary integers in pointer variables.

The details have been discussed on this list previously. The short version is 
that C89 guaranteed that "long" was at least as big as "void *". C99 removed 
this guarantee, and introduced intptr_t instead. To further complicate 
matters the only target (win64) that breaks the C89 guarantee doesn't support 
C99.

Paul