Date: Sun, 25 Jan 2009 09:54:54 -1000 (HST) From: Jeff Roberson <jroberson@jroberson.net> To: Christoph Mallon <christoph.mallon@gmx.de> Cc: svn-src-head@freebsd.org, Jeff Roberson <jeff@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org Subject: Re: svn commit: r187693 - head/sys/kern Message-ID: <20090125095418.G983@desktop> In-Reply-To: <497CC111.70502@gmx.de> References: <200901251838.n0PIcgXk024858@svn.freebsd.org> <20090125085419.O983@desktop> <497CB95A.109@gmx.de> <20090125091247.Y983@desktop> <497CC111.70502@gmx.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 25 Jan 2009, Christoph Mallon wrote: > 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. This is a good point. Since most of C seems to have been designed with the convenience of the compiler writer in mind it's probably the right answer. Thanks, Jeff > >> 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090125095418.G983>