Yes, I misspoke, unsigned( int) to int is conversion not so undefined wrt 0.
I was also thinking about what is actually a uint32_t to int conversion, that may lead to truncation if sizeof(int) < 4, but I guess these archs aren't supported by APR already, since there is no (assembly) code to rely on/fix... I admit the patch isn't strictly necessary, it just make the return value consistent on all compilers, and won't let a code reader think (s)he can use the (new) return value because (s)he currently use this OS with that compiler, it has happened ;) As an APR user, I'd prefer the return value to be a real boolean (0 or 1, so that I could xor it without using !=0), rather than a undefined/compiler-dependent non-zero. As a lib, APR should be consitent accross platforms (IMHO), though letting those who know where they run (what they do) play with the API can be a choice too. My +0.9cts, regards, Yann. On Wed, Jan 8, 2014 at 5:26 PM, Jim Jagielski <[email protected]> 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 <[email protected]> wrote: > > > On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski <[email protected]> wrote: > > > > On Jan 7, 2014, at 3:15 PM, Jeff Trawick <[email protected]> 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. > >
