[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

serf_bucket_response_status

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 20 Apr 2010 11:15:57 +0100

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
Received on 2010-04-20 12:16:36 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.