From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49958) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UjZJx-0002m6-1M for qemu-devel@nongnu.org; Mon, 03 Jun 2013 14:17:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UjZJt-0002CV-3B for qemu-devel@nongnu.org; Mon, 03 Jun 2013 14:17:28 -0400 Message-ID: <51ACDE38.6050708@redhat.com> Date: Mon, 03 Jun 2013 20:19:36 +0200 From: Laszlo Ersek MIME-Version: 1.0 References: <1370251243-20352-1-git-send-email-mjt@msgid.tls.msk.ru> <51AC8D38.90205@redhat.com> <51AC8F21.3070109@msgid.tls.msk.ru> In-Reply-To: <51AC8F21.3070109@msgid.tls.msk.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH trivial] acpi: actually require either data= or file= for -acpitable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Michael Tokarev Cc: qemu-trivial@nongnu.org, qemu-devel@nongnu.org On 06/03/13 14:42, Michael Tokarev wrote: > 03.06.2013 16:34, Eric Blake wrote: >> On 06/03/2013 03:20 AM, Michael Tokarev wrote: >>> Initially the code ensured that we have exactly one of data= or file= option for -acpitable. But after some transformations, the condition becomes >>> >>> if (has_data == has_file) { error } >>> >>> to mean, probably, that both should not be set at the same time. But this condition does not cover the case when neither is set, and we generate bogus acpi table in this case. >>> >>> Instead, check if sum of the two is exactly 1. >>> >>> Signed-off-by: Michael Tokarev --- hw/acpi/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/hw/acpi/core.c b/hw/acpi/core.c index 42eeace..2815d8c 100644 --- a/hw/acpi/core.c +++ b/hw/acpi/core.c @@ -249,7 +249,7 @@ void acpi_table_add(const QemuOpts *opts, Error **errp) if (err) { goto out; } - if (hdrs->has_file == hdrs->has_data) { >> >> NACK. >> >> hdrs->has_file and hdrs->has_data are both bool. > > Yup. > >> Pre-patch, the table of possible combinations is: >> >> false == false => error message, zero given false == true => okay, exactly one given true == false => okay, exactly one given true == true => error message, two given >> >> which is already what you want. > > Ok, you're right. Thank you for spotting this! > > This function has another error -- if the file specified > (either for data= or file=) can't be read, it happily > continues instead of erroring out. _That_ is the bug > I tried to hunt but catched something else entirely ;) > > Will send a real fix later today... :) Please CC me; IIRC I sought to test this code reasonably deeply when I wrote / transformed it. I'm curious. Thanks, Laszlo