lkml.org 
[lkml]   [2000]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Recent change in tcp_output.c is surely wrong
From
Date
R.E.Wolff@BitWizard.nl (Rogier Wolff) writes:

> > > Oh, by the way, ANSI defines the behaviour as undefined, as a compiler
> > > is allowed to recognize that (var <<1) >> 1 evaluates to "var" if done
> > > with arbitrary precision.
> >
> > No. For any unsigned type as wide or wider than `unsigned int', that
> > will clear the top bits. For narrower unsigned types it won't. For
> > signed types it is implementation defined.
>
> Hmm. I'm not too familiar with the exact wording of ANSI. However,
> they usually take the road where "more accuracy in intermediates is
> allowed", as that can normally only reduce the amount of trouble that
> you get into when things near the limit of the size you're using.

From ANSI 6.3.7 "Bitwise shift operators":

$ The result of E1 << E2 is E1 left-shifted E2 bit positions;
$ vacated bits are filled with zeros. If E1 has an unsigned type,
$ the value of the result is E1 multiplied by the quantity, 2
$ raised to the power E2, reduce modulo ULONG_MAX+1 if E1 has type
$ unsigned long, UINT_MAX+1 if otherwise.

--
"To prepare for the writing of Software,
the writer must first become one with it,
sometimes two."
--W. C. Carlson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.708 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site