From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JAq5X-0002GH-5v for qemu-devel@nongnu.org; Fri, 04 Jan 2008 12:12:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JAq5V-0002EV-LV for qemu-devel@nongnu.org; Fri, 04 Jan 2008 12:12:06 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JAq5V-0002EJ-D7 for qemu-devel@nongnu.org; Fri, 04 Jan 2008 12:12:05 -0500 Received: from bsdimp.com ([199.45.160.85] helo=harmony.bsdimp.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JAq5U-0006HQ-Un for qemu-devel@nongnu.org; Fri, 04 Jan 2008 12:12:05 -0500 Date: Fri, 04 Jan 2008 10:10:44 -0700 (MST) Message-Id: <20080104.101044.-861066132.imp@bsdimp.com> Subject: Re: [Qemu-devel] [PATCH] ensure all invocations to bdrv_{read, write} use (uint8_t *) for its third parameter From: "M. Warner Losh" In-Reply-To: <9C6EAA0B-8DBC-4871-AC1B-6E21B31E92FC@web.de> References: <391FA8ED-AD24-4AFC-915E-5609235542F1@web.de> <20080104140030.GH5666@implementation.uk.xensource.com> <9C6EAA0B-8DBC-4871-AC1B-6E21B31E92FC@web.de> Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org, andreas.faerber@web.de In message: <9C6EAA0B-8DBC-4871-AC1B-6E21B31E92FC@web.de> Andreas_F=E4rber writes: : = : Am 04.01.2008 um 15:00 schrieb Samuel Thibault: : = : > Andreas F=E4rber, le Fri 04 Jan 2008 14:41:29 +0100, a =E9crit : : >> : >> Am 04.01.2008 um 14:20 schrieb Thiemo Seufer: : >> : >>> Carlo Marcelo Arenas Belon wrote: : >>>> Trivial fix that ensures that all buffers used for bdrv_read or : >>>> bdrv_write : >>>> are from an array of the uint8_t type : >>> : >>> Do we have a host where this actually makes a difference? : >> : >> I believe Perl makes sizeof(char) checks, so there likely is some : >> platform where sizeof(char) > 1. : > : > The C standard says : > : > `When applied to an operand that has type char, unsigned char, or = : > signed : > char, (or a qualified version thereof) the result is 1.' : = : The standard maybe. But Win64 violates the C standards, too. ;) : = : According to our department's ANSI C course, the only consistent rule= is : sizeof(char) <=3D sizeof(short) <=3D sizeof(int) <=3D sizeof(long) : without any concrete numbers. : = : I'm not saying it should be changed or not in QEMU, just saying it ma= y = : not be completely out-of-the-world. The problem is that sizeof(char) has to be 1, or a number of things will down right fail. The following code will fail if it doesn't: char *a =3D "abc"; char *b =3D malloc(strlen(a) + 1); strcpy(b, a); If sizeof(char) is really 2, then sizeof("abc") is going to be 6, not 3 that strlen returns and the strcpy will smash into memory it doesn't own. And *NOBODY*, not even ignorant students, adds a '* sizeof(char)' to the strlen. Such a compiler would break just about every program out there of any significant size. Now, there's a wchar_t which is the type of the characters in a L string: "abc"L can be 4, 8, 12, 16 or more bytes in size, but that's different, and not what's being discussed. Warner