From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60561 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Phf3m-0003Uo-7d for qemu-devel@nongnu.org; Tue, 25 Jan 2011 04:19:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Phf3g-00066P-PU for qemu-devel@nongnu.org; Tue, 25 Jan 2011 04:19:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40783) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Phf3g-00066L-Hx for qemu-devel@nongnu.org; Tue, 25 Jan 2011 04:19:28 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0P9JRGT003929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Jan 2011 04:19:28 -0500 Message-ID: <4D3E959E.9010803@redhat.com> Date: Tue, 25 Jan 2011 10:19:26 +0100 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 4/4] strtosz(): Use suffix macros in switch() statement References: <1295883211-18288-1-git-send-email-Jes.Sorensen@redhat.com> <1295883211-18288-5-git-send-email-Jes.Sorensen@redhat.com> <4D3DA473.1070704@redhat.com> <4D3DABBD.5020706@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster Cc: kwolf@redhat.com, qemu-devel@nongnu.org On 01/24/11 18:47, Markus Armbruster wrote: > Jes Sorensen writes: >>>>> qemu_toupper() - whats the problem? >>> If a STRTOSZ_DEFSUFFIX_T? expands to a lower case character, its case >>> will not match any input. >> >> Right, so one has to be careful when adding new suffix constants. > > Calls for a comment right next to the definition of the > STRTOSZ_DEFSUFFIX_T*. > > I hate unstated restrictions that are hidden far away from the place > where you can break them. Well I am fine with a comment in the code. >> However given that we already have all the likely to be used ones for >> the near future, that isn't exactly a big issue. >> >> On the other hand forcing the use of the macros makes it less likely >> that someone specifies an unsupported constant by hitting 'y' instead of >> 't' or similar. > > Takes a combination of butterfingers, cross-eyedness, and near-total > incompetence at basic smoke-testing. Not really, all it takes is someone writing a piece of code, not thinking about it, therefore only testing things where a suffix is specified as an argument and it gets missed. Jes