diff options
author | Jeff King <peff@peff.net> | 2012-08-13 21:59:27 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2012-08-13 21:52:36 -0700 |
commit | 9442710801b0b7b9aeefe60408d1835af138cfcc (patch) | |
tree | 3c4607b55efcc78035c7beb5091aa28dcd9af860 /t/t5515 | |
parent | fetch-pack: do not ask for unadvertised capabilities (diff) | |
download | tgif-9442710801b0b7b9aeefe60408d1835af138cfcc.tar.xz |
parse_feature_request: make it easier to see feature values
We already take care to parse key/value capabilities like
"foo=bar", but the code does not provide a good way of
actually finding out what is on the right-hand side of the
"=".
A server using "parse_feature_request" could accomplish this
with some extra parsing. You must skip past the "key"
portion manually, check for "=" versus NUL or space, and
then find the length by searching for the next space (or
NUL). But clients can't even do that, since the
"server_supports" interface does not even return the
pointer.
Instead, let's have our parser share more information by
providing a pointer to the value and its length. The
"parse_feature_value" function returns a pointer to the
feature's value portion, along with the length of the value.
If the feature is missing, NULL is returned. If it does not
have an "=", then a zero-length value is returned.
Similarly, "server_feature_value" behaves in the same way,
but always checks the static server_feature_list variable.
We can then implement "server_supports" in terms of
"server_feature_value". We cannot implement the original
"parse_feature_request" in terms of our new function,
because it returned a pointer to the beginning of the
feature. However, no callers actually cared about the value
of the returned pointer, so we can simplify it to a boolean
just as we do for "server_supports".
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5515')
0 files changed, 0 insertions, 0 deletions