From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Nh4OX-00056E-Ty for mharc-grub-devel@gnu.org; Mon, 15 Feb 2010 12:06:01 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nh4OU-00054M-Fo for grub-devel@gnu.org; Mon, 15 Feb 2010 12:05:58 -0500 Received: from [140.186.70.92] (port=34588 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nh4OT-00053Y-8U for grub-devel@gnu.org; Mon, 15 Feb 2010 12:05:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nh4OS-0008Tu-Ed for grub-devel@gnu.org; Mon, 15 Feb 2010 12:05:57 -0500 Received: from gator297.hostgator.com ([74.53.228.114]:57760) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nh4OS-0008Tb-7s for grub-devel@gnu.org; Mon, 15 Feb 2010 12:05:56 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gibibit.com; h=Received:Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; b=BrCGmYESlVlrXPvvIuzJ6BMV4UyNllAxojaxmqwEIjvQwCISoLOeYrjOf3Tb6gv513RT7EV+OtFNB9BKLWjV3nw5YJyN1C0AJglGaWNB2zAwYB4EYesEVcQM69T+nMI+; Received: from c-67-185-87-185.hsd1.wa.comcast.net ([67.185.87.185]:42218 helo=svelte) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Nh4OP-0000Kp-AD; Mon, 15 Feb 2010 11:05:53 -0600 Date: Mon, 15 Feb 2010 09:05:52 -0800 From: Colin D Bennett To: The development of GNU GRUB Message-ID: <20100215090552.047346bf@svelte> In-Reply-To: References: <4B736F82.7010005@gmail.com> <4B742B70.3080303@gmail.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.18.3; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: hramrach@centrum.cz Subject: Re: [RFC] Framebuffer rotation patch, or why 'unsigned' fails us X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2010 17:05:58 -0000 On Sat, 13 Feb 2010 18:29:41 +0100 Michal Suchanek wrote: > 2010/2/11 Vladimir '=CF=86-coder/phcoder' Serbinenko : > > Michal Suchanek wrote: > >> 2010/2/11 Vladimir '=CF=86-coder/phcoder' Serbinenko > >> : > >> > >>> Michal Suchanek wrote: > >>> - =C2=A0 =C2=A0unsigned int x; > >>> - =C2=A0 =C2=A0unsigned int y; > >>> - =C2=A0 =C2=A0unsigned int width; > >>> - =C2=A0 =C2=A0unsigned int height; > >>> + =C2=A0 =C2=A0int x; > >>> + =C2=A0 =C2=A0int y; > >>> + =C2=A0 =C2=A0int width; > >>> + =C2=A0 =C2=A0int height; > >>> Why do you need negative values? > >>> > >> > >> I don't need the negative values everywhere but this change was to > >> align the typing so that casts are not required. > >> > >> > > Perhaps few casts together with appropiate checks when casting is > > better than potentially exposing the whole code to the values it's > > not intended for. >=20 > How is it exposed to more unwanted values than now? > It uses the variables only to store the viewport dimensions and at > most adds a border around it. The unsigned integer is able to > represent values outside of the viewport as much as signed integers > are, only signed integer can represent values outside of viewport in > both directions. The unwanted values (if erroneously calculated which > does not seem to be the case here) are clipped by the viewport > clipping in video_fb. >=20 > On the other hand, there would be more than a few casts as the > variables are used multiple times and the interface now uses signed > integers. I have to chime in on this one since I've learned the hard way that 'unsigned' doesn't pull its weight in these use cases. Using unsigned integer values in C when a lot of arithmetic is performed (as in graphics programming) is really a nightmare. Well, maybe if you are a grand master C programmer you would remember when you need to cast and never make a mistake, but remember that there are us mere mortals who would benefit by more logical and predictable code behavior. (I use 'predictable' not in the sense that expressions involving both signed and unsigned values are have an undefined result, but rather that it's usually not the obvious result that the average C programmer would expect at first glance. Certainly it would be nice if we could use the 'unsigned' qualifier to enforce an invariant requiring only non-negative values be stored in it (which it technically does, but it doesn't necessarily make the result any more correct). It almost never really fixes the kind of problems we'd like it to. We could easily try to store the result of a subtraction that conceptually should produce a negative value into an unsigned variable, and--OOPS!--we now have an enormous value instead of a negative value. Not much better. More significant is code that involves multiple operations such that the result of the entire expression should be nonnegative, but it involves temporary negative values in subexpressions such that the implicit signed-unsigned conversion produces the "wrong" result (i.e., not what the programmer intended even though the expression looks correct). Let me quote an entry from my gfxmenu project journal, 31 May 2008: It is worthwhile noting the potential perils of unsigned types in C (and C++). I spent a lot of time trying to figure out why my apparently simple code was not working. It turns out that I had expressions that combined signed and unsigned integral types. The unsigned types were the viewport origin/size, which GRUB defines to be unsigned, and one of the signed types was an offset that was added to the bitmap position during the animation. This offset had to be signed since it could be either positive or negative, depending on the present direction of the bitmap's movement. The final solution was to use signed types only. I read some discussions on signed vs. unsigned types and found this quote from Bjarne Stroustrup, which in my experience is wise advice: The unsigned integer types are ideal for uses that treat storage as a bit array. Using an unsigned instead of an int to gain one more bit to represent positive integers is almost never a good idea. Attempts to ensure that some values are positive by declaring variables unsigned will typically be defeated by the implicit conversion rules. Anyway, that's my two cents after having been bitten by arithmetic involving both signed an unsigned values. And it's tedious to go check the exact types of each value involved in an expression just to see what casts you might need to produce the right result, especially when the values involved are declared far away in some header file (i.e., structure members). Regards, Colin