serf_bucket_response_status

[Philip Martin]

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