If a is unsigned int and its value is, say, 10, then the conversion (int)a is allowed, since that value (10) can be expressed both as a signed int or an unsigned one.
However, if a is 4,294,967,200, then the behavior of (int)a is undefined and implementation dependent, since you can't express that value within the limits of a signed int (assuming 32 bits). My point is that the possibility in that case of (int)a resulting in 0 is pretty freakin' remote, even if it is undefined behavior ;) On Jan 8, 2014, at 5:42 PM, Player, Grady <grady.pla...@mozy.com> wrote: > int and unsigned are both by definition ‘int' sized and will have the same > truthiness for all values; > that is false for 0 and true for any non-zero value… it doesn’t matter how > the bits are interpreted because there is no truncation and no possible > mis-interpretation. > > > On Jan 8, 2014, at 9:26 AM, Jim Jagielski <j...@jagunet.com> wrote: > >> If the unsigned quantity can be expressed as a signed >> quantity, then all is well. The only undefined behavior >> (implementation specific) is if it can't be. However, >> the conversion from a non-0 quantity to a 0 would >> be extremely unlikely. You'd get an unexpected signed >> value, but I can't imagine any compiler turning it >> into a 0! >> >> On Jan 8, 2014, at 10:57 AM, Yann Ylavic <ylavic....@gmail.com> wrote: >> >>> On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski <j...@jagunet.com> wrote: >>> >>> On Jan 7, 2014, at 3:15 PM, Jeff Trawick <traw...@gmail.com> wrote: >>>> >>>> +1 for APR trunk, +0.9 for future APR 1.6.x, -0.9 for APR 1.5.x... >>>> >>>> alternate opinions? >>>> >>> >>> As far as I know, C guarantees that >>> >>> if (a) >>> >>> is the same as >>> >>> if (a != 0) >>> >>> So I'm unsure of the need for this patch. >>> >>> The real question is, for an "unsigned a != 0", can "(int)a" become 0 after >>> an implicit (undefined) conversion? >>> >>> Regards, >>> Yann. >> >> >
