On Thu, Feb 20, 2014 at 8:00 PM, Ben Reser <[email protected]> wrote: > On 2/20/14, 3:13 AM, Branko Čibej wrote: > > On 20.02.2014 12:08, Stefan Fuhrmann wrote: > >> On Thu, Feb 20, 2014 at 3:13 AM, Branko Čibej <[email protected]> > wrote: > >>> FWIW, I'd be fine with replacing all ints with apr_int32_t in places > where > >>> we interact with apr_array_header_t and similar. Widening promotions > to int > >>> would be automatic, and narrowing conversions on 16-bit platforms would > >>> (presumably) make compilers yell very loudly. > >>> > >> I assume you mean in the SVN code, i.e. at least > >> replace all "(int)"-style casts and then get most of > >> the other places by tedious search-for-APR-macro- > >> and-find-index-variable-declaration. > >> > >> That would be fine with me. > > > > Yup, that's what I meant. Use an explicitly 32-bit signed type in our > code > > instead of casting to int all over the place. > > Seems like a reasonable course of action to me. But we're still going to > have > casts because of our use in apr_size_t in some APIs. >
I tried that approach and realized how many places use ints or unsigneds even in our API. So, I decided to simply codify our implicit assumption that int is 32 bits or wider in r1570882 (with an option to override that check). Another advantage is that we have a better chance to actually take advantage of ILP64 platforms. -- Stefan^2.
