On 02 Dec 2005 17:05:38 -0600, kfogel@collab.net <kfogel@collab.net> wrote:
> Erik Huelsmann <ehuels@gmail.com> writes:
> > > + char keyword_buf[SVN_KEYWORD_MAX_LEN];
> > > + apr_size_t keyword_off;
> > > + char src_format[2];
> >
> > The segment above is from my last commit creating the eol-recoding stream.
> >
> > Here, and some other places in our code, we still use fixed length
> > character buffers. I understand the case where we use them for MD5
> > sums: APR expects us to.
> >
> > In the above case, nobody *wants* us to use a fixed character buffer.
> > Using stringbufs, the above character limit (SVN_KEYWORD_MAX_LEN) can
> > easily be lifted, if we want to.
> >
> > Also, I consider it not very future proof to build a 1.3 client with
> > that constant: if later clients have a higher value for that
> > constant...
>
> Well, we control the keywords, so the only potential problem here is
> that we might one day make a keyword longer than 255 characters and
> forget to update SVN_KEYWORD_MAX_LEN...
We control the keywords, but not for long anymore: large portions of
our code have been adapted for a feature called 'Custom keywords',
which implies, well... that we don't control them....
> ...oh, wait: under some circumstances, that length has to include both
> the keyword and its value. For example, see the strncmp() that
> appears early in libsvn_subr/subst.c:translate_keyword_subst().
>
> Do we have a problem right now? Have we just been lucky that no one's
> had, say, a really long URL as the value of the $URL$ keyword?
I see Garret found an issue on this. Why should we limit the length of
the value? Anyway, I'd be willing to make this instance (and others?)
use stringbufs...
bye,
Erik.
Received on Sat Dec 3 09:43:19 2005