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:
>
>> 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. brane_at_wandisco.com
Received on 2014-02-20 12:13:49 CET