On 02 Dec 2005 17:05:38 -0600, email@example.com <firstname.lastname@example.org> wrote:
> Erik Huelsmann <email@example.com> writes:
> > > + char keyword_buf[SVN_KEYWORD_MAX_LEN];
> > > + apr_size_t keyword_off;
> > > + char src_format;
> > 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?)
Received on Sat Dec 3 09:43:19 2005