On 9/24/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Sat, Sep 22, 2007 at 01:43:40PM -0700, dionisos@tigris.org wrote:
> > Eliminate endless loop edge-case (resolves issue #2577).
> >
> > Before, if no character could be converted, but the remaining buffer size
> > was 3 or more, we'd loop endlessly.
Right, but the theoretical limit (currently) is 4. And since I had to
change the loop anyway (to make it fit the theoretical limit), why
hardcode a limit at all? This shifts the problem
> I must admit that I'm unsure as to how this is possible - do you have an
> example case? (We only convert from UTF-8 <> native, and I don't believe
> there are any native encodings that include characters outside the
> Unicode BMP, or that take more than three [actually, two] bytes per
> character to encode natively).
Not currently, but we also use a special svn_revnum_t - and not an int
- 'just in case'; with which I want to say: it's often hard to find
bugs resulting from hardcoded limits, especially when they're
implicit.
The other option I considered is to define
SVN_UTF__MAX_CHARACTER_OCTETS in the header, which would make it
easier to trace where we're using the maximum character assumption.
That would however require me to trace all assumptions (otherwise I
would be suggesting that this loop is the only place where we have
this assumption). Not having assumptions looked better to me.
> > - } while (! apr_err && srclen);
> > + } while (apr_err == APR_SUCCESS && srclen != 0);
>
> [Is the latter really better than the former? APR_SUCCESS is zero by
> definition.]
Yes, that's true, but using APR_SUCCESS means that we stay source
compatible with APR 2.0 and higher, where they're free to redefine it
to any other value.
> Regards,
> Malcolm
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 24 12:06:08 2007