Re: fsfs-stats potentially busted on some architectures

On 20.02.2014 00:00, Ben Reser wrote:
> Found via the following compiler warning on OS X:
> /Users/breser/wandisco/share/wcs/svn-trunk/tools/server-side/fsfs-stats.c:1556:61:
> warning: implicit conversion loses integer precision: 'long' to 'int'
> [-Wshorten-64-to-32]
> ffd->youngest_rev_cache + 1,
> ~~~~~~~~~~~~~~~~~~~~~~~~^~~
> 1 warning generated.
>
>
> The rest of the statement for that line:
> [[[
> /* create data containers and caches */
> (*fs)->revisions = apr_array_make(pool,
> ffd->youngest_rev_cache + 1,
> sizeof(revision_info_t *));
> ]]]
>
> apr_array_make is declared as:
> apr_array_header_t * apr_array_make (apr_pool_t *p, int nelts, int elt_size)
>
> int is only guaranteed to be 16 bits. We support up to 32-bit revision numbers
> (which technically some platforms supported up to 64-bit revision numbers until
> we recently started enforcing that it stayed under 32-bits in our revision
> string parser).
>
> Thus running fsfs-stats on a machine with a 16-bit int and a repository with
> more than 32768 revisions should have a problem.
>
> I'm not sure if we should care about this. I'm guessing we in general don't
> support 16-bit architectures, which is where this is likely to be a problem.
> We almost certainly have a lot worse problems elsewhere.
>
> I only see two paths to fixing this:
>
> 1) Create a new APR array interface that uses something other than int for the
> size of the array.
>
> 2) Rework the code so that it doesn't need to maintain information about every
> revision. However, this seems like it'd make things much slower due to needing
> to look up rep sharing.

3) Do nothing. Trying to support 16-bit architectures is futile. No-one
will host Subversion servers on microcontrollers.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com