Date: Wed, 5 Oct 2011 19:13:44 -0400 (EDT) From: Benjamin Kaduk <kaduk@MIT.EDU> To: Michael Butler <imb@protected-networks.net> Cc: Gabor Kovesdan <gabor@freebsd.org>, current@freebsd.org Subject: Re: Problem with r226035 - in head/usr.bin/grep: . regex? Message-ID: <alpine.GSO.1.10.1110051907570.882@multics.mit.edu> In-Reply-To: <4E8C6F3C.6090707@protected-networks.net> References: <20111005135000.GE2831@albert.catwhisker.org> <4E8C6E29.1010507@protected-networks.net> <4E8C6F3C.6090707@protected-networks.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 5 Oct 2011, Michael Butler wrote: > On 10/05/11 10:48, I wrote: >> Does this look right? > >> ! ts = ((long)u - v < 0) ? 0 : (u - v); \ > > Doh! It should probably be .. > > ts = ((long)(u - v) < 0) ? 0 : (u - v); This is definitely incorrect. Consider the case where u = (int)INT_MAX, v = (int)INT_MIN. Then (u-v) is evaluated within 'int' width, and overflows, causing undefined behavior (but probably wrapping), which is then cast to long. The cases where either u or v are unsigned types can also provide interesting edge cases. Probably the "most correct" choice is to cast all values to the widest supported signed integral type (since no type information is available within the macro scope), including the 'else' branch of the ternary operator, which is also susceptible to over/underflow. There are many style bugs with macros of this nature, on which bde would presumably be happy to expound. It seems that (at least in the first usage that I found) 'u' and 'v' are declared as unsigned int, so casting everything to signed long is unlikely to introduce breakage in the common case. -Ben Kaduk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.GSO.1.10.1110051907570.882>