From owner-svn-src-head@FreeBSD.ORG Sun Jan 25 19:57:30 2009 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96C55106566C; Sun, 25 Jan 2009 19:57:30 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 5B57D8FC1D; Sun, 25 Jan 2009 19:57:30 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: by rv-out-0506.google.com with SMTP id b25so5675122rvf.43 for ; Sun, 25 Jan 2009 11:57:30 -0800 (PST) Received: by 10.140.165.21 with SMTP id n21mr6412062rve.60.1232913450006; Sun, 25 Jan 2009 11:57:30 -0800 (PST) Received: from ?10.0.1.199? (udp005586uds.hawaiiantel.net [72.234.105.237]) by mx.google.com with ESMTPS id b39sm12311204rvf.0.2009.01.25.11.57.27 (version=SSLv3 cipher=RC4-MD5); Sun, 25 Jan 2009 11:57:28 -0800 (PST) Date: Sun, 25 Jan 2009 09:54:54 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Christoph Mallon In-Reply-To: <497CC111.70502@gmx.de> Message-ID: <20090125095418.G983@desktop> References: <200901251838.n0PIcgXk024858@svn.freebsd.org> <20090125085419.O983@desktop> <497CB95A.109@gmx.de> <20090125091247.Y983@desktop> <497CC111.70502@gmx.de> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="2547152148-139696866-1232913294=:983" Cc: svn-src-head@freebsd.org, Jeff Roberson , src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r187693 - head/sys/kern X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 19:57:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2547152148-139696866-1232913294=:983 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 25 Jan 2009, Christoph Mallon wrote: > Jeff Roberson schrieb: >> On Sun, 25 Jan 2009, Christoph Mallon wrote: >>=20 >>> Jeff Roberson schrieb: >>>> On Sun, 25 Jan 2009, Jeff Roberson wrote: >>>>=20 >>>>> Author: jeff >>>>> Date: Sun Jan 25 18:38:42 2009 >>>>> New Revision: 187693 >>>>> URL: http://svn.freebsd.org/changeset/base/187693 >>>>>=20 >>>>> Log: >>>>> - bit has to be fd_mask to work properly on 64bit platforms.=20 >>>>> Constants >>>>> must also be cast even though the result ultimately is promoted >>>>> to 64bit. >>>>> - Correct a loop index upper bound in selscan(). >>>>=20 >>>> Sorry about that, should've tested my earlier patch for more than a=20 >>>> couple of days. I seldom remember c's integer promotion rules as they= =20 >>>> relate to constants. You'd think they'd make it easy on us and just= =20 >>>> promote it to the largest type in the expression/lvalue. I'm not sure= =20 >>>> why they don't. Perhaps the more careful among you knows the answer. >>>=20 >>> The rule for operations is quite simple: An operation never cares for t= he=20 >>> type of its user. It only uses the type of the operand(s) to determine = its=20 >>> result type. So for a =3D b + c the type of the result of + only depend= s on=20 >>> the types of b and c, but never on a. >>> Integer literals have a bit ugly rules what type they are: It depends o= n=20 >>> the base (!) and on the magnitude of the literal. >>> If in doubt and you need a specific type (and maybe making it more clea= r=20 >>> for a reader) then cast. >>>=20 >>=20 >> I'm familiar with the rule, what I don't know is the rationale. It=20 >> would've been much more convenient if they did care for the user. > > Well, the only rationale which really matters in the end is that it alway= s=20 > was this way and therefore it cannot be changed anymore, because there ar= e=20 > billions and billions of lines of code out there. > > The technical reason probably was that it makes type analysis easier in t= he=20 > compiler: You only have to propagate type information from the leaves of = an=20 > expression twoards the root instead of having to do so in both directions= =2E This is a good point. Since most of C seems to have been designed with=20 the convenience of the compiler writer in mind it's probably the right=20 answer. Thanks, Jeff > >> In what case does the base matter? If you use a literal large enough th= e=20 >> compiler conveniently complains. However, in this case the shift value = was=20 >> computed and applied to 1 which overflowed before being assigned to a 64= bit=20 >> value. > > Decimal literals which do not have a "U" as part of the suffix are always= of=20 > a signed integer type. In contrast octal and hexadecimal literals can be = of=20 > unsigned integer types, too. > Example: (assuming 32bit int and long, 64bit long long) > 0xFFFFFFFF is unsigned int > but > 4294967295 is signed long long int > The exact rules can be found in ISO/IEC 9899:1999(E) =A76.4.4.1. > > Btw: There are no negative literals. This is always a unary minus operato= r=20 > followed by a (non-negative) integer literal. This leads to one interesti= ng=20 > edge case on two complement machines: the number -2147483648 fits into a= =20 > signed int. But it is parsed as unary minus operator with a integer liter= al=20 > as operand. The integer literal is too large for int, so its type is sign= ed=20 > long long int. Therefore -2147483648 is of type signed long long int inst= ead=20 > of the expected int. This artifact is mostly harmless though. > --2547152148-139696866-1232913294=:983--