From owner-svn-src-all@FreeBSD.ORG Sun Jan 25 19:44:37 2009 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EA9F1065677 for ; Sun, 25 Jan 2009 19:44:37 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 91E108FC1B for ; Sun, 25 Jan 2009 19:44:36 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 25 Jan 2009 19:44:31 -0000 Received: from p54A3D748.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.215.72] by mail.gmx.net (mp066) with SMTP; 25 Jan 2009 20:44:31 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18uRv8eynYuBsq87M0K7nCvg83/uLx6FeAYG/Acib YX3aCAlnUeHCGO Message-ID: <497CC111.70502@gmx.de> Date: Sun, 25 Jan 2009 20:44:17 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Jeff Roberson References: <200901251838.n0PIcgXk024858@svn.freebsd.org> <20090125085419.O983@desktop> <497CB95A.109@gmx.de> <20090125091247.Y983@desktop> In-Reply-To: <20090125091247.Y983@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 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-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jan 2009 19:44:38 -0000 Jeff Roberson schrieb: > On Sun, 25 Jan 2009, Christoph Mallon wrote: > >> Jeff Roberson schrieb: >>> On Sun, 25 Jan 2009, Jeff Roberson wrote: >>> >>>> Author: jeff >>>> Date: Sun Jan 25 18:38:42 2009 >>>> New Revision: 187693 >>>> URL: http://svn.freebsd.org/changeset/base/187693 >>>> >>>> Log: >>>> - bit has to be fd_mask to work properly on 64bit platforms. >>>> Constants >>>> must also be cast even though the result ultimately is promoted >>>> to 64bit. >>>> - Correct a loop index upper bound in selscan(). >>> >>> Sorry about that, should've tested my earlier patch for more than a >>> couple of days. I seldom remember c's integer promotion rules as >>> they relate to constants. You'd think they'd make it easy on us and >>> just promote it to the largest type in the expression/lvalue. I'm >>> not sure why they don't. Perhaps the more careful among you knows the >>> answer. >> >> The rule for operations is quite simple: An operation never cares for >> the type of its user. It only uses the type of the operand(s) to >> determine its result type. So for a = b + c the type of the result of >> + only depends on the types of b and c, but never on a. >> Integer literals have a bit ugly rules what type they are: It depends >> on the base (!) and on the magnitude of the literal. >> If in doubt and you need a specific type (and maybe making it more >> clear for a reader) then cast. >> > > I'm familiar with the rule, what I don't know is the rationale. It > 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 always was this way and therefore it cannot be changed anymore, because there are billions and billions of lines of code out there. The technical reason probably was that it makes type analysis easier in the compiler: You only have to propagate type information from the leaves of an expression twoards the root instead of having to do so in both directions. > In what case does the base matter? If you use a literal large enough > the compiler conveniently complains. However, in this case the shift > value was computed and applied to 1 which overflowed before being > assigned to a 64bit value. Decimal literals which do not have a "U" as part of the suffix are always of a signed integer type. In contrast octal and hexadecimal literals can be of 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) §6.4.4.1. Btw: There are no negative literals. This is always a unary minus operator followed by a (non-negative) integer literal. This leads to one interesting edge case on two complement machines: the number -2147483648 fits into a signed int. But it is parsed as unary minus operator with a integer literal as operand. The integer literal is too large for int, so its type is signed long long int. Therefore -2147483648 is of type signed long long int instead of the expected int. This artifact is mostly harmless though.