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. [email protected]
