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,

On Wed, Jan 8, 2014 at 5:26 PM, Jim Jagielski <> 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 <> wrote:

> On Wed, Jan 8, 2014 at 2:03 PM, Jim Jagielski <> wrote:
> On Jan 7, 2014, at 3:15 PM, Jeff Trawick <> 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.