In message: <[EMAIL PROTECTED]> Andreas_Färber <[EMAIL PROTECTED]> writes: : : Am 04.01.2008 um 15:00 schrieb Samuel Thibault: : : > Andreas Färber, le Fri 04 Jan 2008 14:41:29 +0100, a écrit : : >> : >> 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) <= sizeof(short) <= sizeof(int) <= sizeof(long) : without any concrete numbers. : : I'm not saying it should be changed or not in QEMU, just saying it may : 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 = "abc"; char *b = 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