Re: [Qemu-devel] [PATCH] ensure all invocations to bdrv_{read, write} use (uint8_t *) for its third parameter

[M. Warner Losh]

In message: <address@hidden>
            Andreas_Färber <address@hidden> 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