On May 9, 2011 10:48 AM, "Julian Foad" <julian.foad_at_wandisco.com> wrote:
>
> Hyrum K Wright wrote:
> > On Sun, May 8, 2011 at 3:34 AM, <rhuijben_at_apache.org> wrote:
> > > - for (i = relpath_depth(local_relpath); i > op_depth; --i)
> > > + for (i = (int)relpath_depth(local_relpath); i > op_depth; --i)
> > >
> > > - for (i = relpath_depth(current_relpath); i > op_depth; i--)
> > > + for (i = (int)relpath_depth(current_relpath); i > op_depth;
i--)
> > >
> > > - lock_depth = relpath_depth(local_relpath);
> > > + lock_depth = (int)relpath_depth(local_relpath);
> > >
> > > - levels += relpath_depth(lock_relpath);
> > > + levels += (int)relpath_depth(lock_relpath);
> > >
> > > - int depth = relpath_depth(local_relpath);
> > > + int depth = (int)relpath_depth(local_relpath);
> > >
> > > - lock_level = relpath_depth(local_relpath);
> > > + lock_level = (int)relpath_depth(local_relpath);
>
> > Instead of all the casting, why don't we just change the types of the
> > various local variables?
>
> Alternatively... I'd like to change all our uses of apr_int64_t for
> (wc_id, repos_id, op_depth) to plain "int". I think that would be
> better because it would only occupy one syllable of thought-space rather
> than eight syllables. And I believe there's no functional or
> programmatic reason or benefit for having these three types be int64_t.
>
> To do that, I would need to introduce an additional type letter into the
> "bindf" format, because some parameters will still need to be int64_t (I
> can't remember what, but I looked at this before and there were some).
apr_time_t
I think the FS might store 64-bit values.
> Note that revnum_t is not relevant because it already has its own type
> letter "r".
>
> I was thinking like this, in sequential steps:
>
> 1. In "bindf" introduce letter "I" for int64_t (in parallel with the
> current "i" which is currently for int64_t).
I'm with Philip on this. I thought about adding a "long" type a while back,
in addition to the 64-bit, but figured that would lead to more mismatches.
>...
Cheers,
-g
Received on 2011-05-09 20:12:05 CEST