From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KixH8-0003Rc-RL for qemu-devel@nongnu.org; Thu, 25 Sep 2008 16:17:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KixH7-0003RM-Kz for qemu-devel@nongnu.org; Thu, 25 Sep 2008 16:17:21 -0400 Received: from [199.232.76.173] (port=54203 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KixH7-0003RJ-DG for qemu-devel@nongnu.org; Thu, 25 Sep 2008 16:17:21 -0400 Received: from wf-out-1314.google.com ([209.85.200.168]:41841) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KixH7-00046J-1N for qemu-devel@nongnu.org; Thu, 25 Sep 2008 16:17:21 -0400 Received: by wf-out-1314.google.com with SMTP id 27so680875wfd.4 for ; Thu, 25 Sep 2008 13:17:20 -0700 (PDT) Message-ID: Date: Thu, 25 Sep 2008 23:17:20 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [5274] Add signed versions of save/load functions In-Reply-To: <48DBEDBC.80400@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48DBEDBC.80400@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On 9/25/08, Anthony Liguori wrote: > Blue Swirl wrote: > > > -int qemu_get_byte(QEMUFile *f) > > +int8_t qemu_get_byte(QEMUFile *f) > > { > > if (f->buf_index >= f->buf_size) { > > qemu_fill_buffer(f); > > @@ -6329,13 +6329,13 @@ > > return pos; > > } > > > > > > So this is the problem. While qemu_get_byte() returns an int, it returns > f->buf[pos] and buf is a uint8_t *. This means that it will always return a > positive number whereas the new qemu_get_byte() may return a negative > number. > > When dealing with something like qemu_get_be32(), where you're shifting > qemu_get_byte(), the int8_t is going to get promoted to an int and when the > int8_t is negative, the result is that the combination is an OR of > 0xFFFFFFFX instead of 0x000000FX. > > Which leads me to wonder, how much did you test this changeset? Because I > don't think any save/restore could possibly have worked. Perhaps we should > revert the whole patchset until it's a bit more flushed out? I'm concerned > that integer promotion isn't taken into account in a number of places. Right. I think the patch should be split into three operations: signed version addition, int to size_t change and this dangerous type size change. Only the first one is obviously correct, which I thought all of these changes were. Thanks for debugging, I'll revert this patch and make new patches for review.