[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: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Thu, 20 Feb 2014 12:08:23 +0100

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.

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.

-- Stefan^2.
Received on 2014-02-20 12:09:06 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.