On Mon, Sep 24, 2007 at 12:05:55PM +0200, Erik Huelsmann wrote:
> > 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.
>
Fair enough. I was just wondering whether you had an example to
demonstrate the problem, since it appeared like the case you were fixing
was 'impossible'. (And I agree that something being 'impossible' is no
reason to avoid fixing it, especially if you can simplify the code :-)).
> > > - } 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.
>
Sure, though I had got the impression that the current guidance was to
avoid APR_SUCCESS completely because it was deprecated or similar.
However, I can't find any reference to that, so I've probably
mis-remembered.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Mon Sep 24 14:25:16 2007