From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45398 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhhTf-0004wO-JE for qemu-devel@nongnu.org; Tue, 25 Jan 2011 06:54:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhhTe-0001pf-LX for qemu-devel@nongnu.org; Tue, 25 Jan 2011 06:54:27 -0500 Received: from mx1.redhat.com ([209.132.183.28]:53975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhhTe-0001pV-DY for qemu-devel@nongnu.org; Tue, 25 Jan 2011 06:54:26 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id p0PBsPcT002453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 25 Jan 2011 06:54:25 -0500 Message-ID: <4D3EB9EF.9020400@redhat.com> Date: Tue, 25 Jan 2011 12:54:23 +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> <4D3E959E.9010803@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/25/11 11:17, Markus Armbruster wrote: > Jes Sorensen writes: > >> 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. > > Such a comment improves it from "wrong" to merely "ugly". I can live > with that. I realize that you view it as such, in other eyes it goes from hackish to correct ... there is zero point in arguing over this, we can just agree to disagree. Jes