[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: fsfs-stats potentially busted on some architectures

From: Branko Čibej <brane_at_wandisco.com>
Date: Thu, 20 Feb 2014 12:13:10 +0100

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.


-- Brane

Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-02-20 12:13:49 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.