You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2010/04/20 10:15:57 UTC
serf_bucket_response_status
Recent versions of GCC warn about variables that get assigned but not
otherwise used. In libsvn_ra_serf we have:
../src/subversion/libsvn_ra_serf/locks.c:363:20: warning: variable ‘rv’ set but not used
../src/subversion/libsvn_ra_serf/util.c:823:20: warning: variable ‘rv’ set but not used
../src/subversion/libsvn_ra_serf/util.c:983:20: warning: variable ‘rv’ set but n
these all involve calls:
apr_status_t rv;
rv = serf_bucket_response_status(response, &sl);
where rv is ignored. This prompted me to look at the other calls to
serf_bucket_response_status and some of them don't simply don't store
the return value.
Looking in the serf test suite I see things like:
static apr_status_t handle_response(serf_request_t *request,
serf_bucket_t *response,
void *handler_baton,
apr_pool_t *pool)
{
const char *data;
apr_size_t len;
serf_status_line sl;
apr_status_t status;
handler_baton_t *ctx = handler_baton;
status = serf_bucket_response_status(response, &sl);
if (status) {
if (APR_STATUS_IS_EAGAIN(status)) {
return status;
}
abort();
}
In some cases, such as the util.c:823 and util.c:983, where an error
is being handled it is probably correct to ignore the return value
(although we could remove the variable and thus the warning). However
in cases like svn_ra_serf__handle_xml_parser which just does:
serf_bucket_response_status(response, &sl);
and locks.c:363, is it acceptable to ignore the potential for
APR_STATUS_IS_EAGAIN?
--
Philip