From owner-freebsd-current@FreeBSD.ORG Wed Oct 5 23:13:50 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF306106564A for ; Wed, 5 Oct 2011 23:13:50 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5D8988FC0A for ; Wed, 5 Oct 2011 23:13:49 +0000 (UTC) X-AuditID: 1209190c-b7fd26d0000008df-ee-4e8ce4ad145c Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E3.47.02271.DA4EC8E4; Wed, 5 Oct 2011 19:13:49 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id p95NDm6f010975; Wed, 5 Oct 2011 19:13:48 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p95NDiqJ023166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 5 Oct 2011 19:13:46 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p95NDiA6004516; Wed, 5 Oct 2011 19:13:44 -0400 (EDT) Date: Wed, 5 Oct 2011 19:13:44 -0400 (EDT) From: Benjamin Kaduk To: Michael Butler In-Reply-To: <4E8C6F3C.6090707@protected-networks.net> Message-ID: References: <20111005135000.GE2831@albert.catwhisker.org> <4E8C6E29.1010507@protected-networks.net> <4E8C6F3C.6090707@protected-networks.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUixG6nrrv2SY+fwYnrEhYTrvxgsjj15S6L xbJHG9ksFkyZy+7A4rHwST+zx4xP81k8Fk35yBjAHMVlk5Kak1mWWqRvl8CVMfnWaZaCVs6K M/t/sDUwdrJ3MXJySAiYSDxvuM0KYYtJXLi3nq2LkYtDSGAfo8SF3hfsEM56Rol7rycwQzj7 mSRaO6exgbQICdRL3O18xwxiswhoSWxZuwLMZhNQkZj5ZiNYjYiAvsTtg8/B1jEL5EjMW3af EcQWFnCSOP7jN5jNKWAm8X/DeiYQm1fAXuL0sucsEMt6GSXufoRIiAroSKzeP4UFokhQ4uTM JywQQy0lzv25zjaBUXAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdA31cjNL9FJT SjcxgkKZU5JnB+Obg0qHGAU4GJV4eIV7e/yEWBPLiitzDzFKcjApifJ+eQwU4kvKT6nMSCzO iC8qzUktPsQowcGsJMLrXw6U401JrKxKLcqHSUlzsCiJ8x7c4eAnJJCeWJKanZpakFoEk5Xh 4FCS4P0OMlSwKDU9tSItM6cEIc3EwQkynAdouPoTkOHFBYm5xZnpEPlTjIpS4rxCIAkBkERG aR5cLyzVvGIUB3pFmNcIpIoHmKbgul8BDWYCGsx/HWxwSSJCSqqBcduJr97Mhtq2O522ztvy Z3L2pRqNGpZ3p3b4dGmIFZUU9kWw35e66LF7m4jFrhtr4nceF3SLzGBvMJLUyDx0j9G133Sv /VUZt48x7y8fVNfLO1jLdrTS3nRzpfaliONhUxTZfrXNClwcpr7/TEjQix3TM1UnJEsJLlzx KJ+zeuK0pASnLT/rlFiKMxINtZiLihMB9gEwEBADAAA= Cc: Gabor Kovesdan , current@freebsd.org Subject: Re: Problem with r226035 - in head/usr.bin/grep: . regex? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:13:50 -0000 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