On 20.02.2014 12:08, Stefan Fuhrmann wrote: > On Thu, Feb 20, 2014 at 3:13 AM, Branko Čibej <[email protected]> wrote: > >> On 20.02.2014 02:52, Ben Reser wrote: >> >> On 2/19/14, 5:30 PM, Branko Čibej wrote: >> >> 3) Do nothing. Trying to support 16-bit architectures is futile. No-one will >> host Subversion servers on microcontrollers. >> >> SVN is already "broken" on systems like 16 bit DOS > since we use those arrays (at least as intermediates) > for things like the changed paths list and directories. > Both would be limited to 32k entries. > >> I'm perfectly fine with that decision. I just wanted some feedback before I >> hid the limitation with a typecast. >> >> >> 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. > The only reason *not* to do that is marginally worse performance on some >> 64-bit platforms. >> > If even. In super tight loops we access the elts > array directly, so there is no further conversion > needed. Ack. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. [email protected]
