svn commit: r187693 - head/sys/kern

[Jeff Roberson]

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.

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.

Thanks,
Jeff