On Thu, Feb 20, 2014 at 8:00 PM, Ben Reser <ben_at_reser.org> 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 <brane_at_wandisco.com>
> 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.
Received on 2014-02-22 20:05:23 CET