Re: subversion/libsvn_wc/update_editor.c compile warning

Philip Martin wrote:
> Blair Zajac <blair@orcaware.com> writes:
>
>>subversion/libsvn_wc/update_editor.c: In function `install_file':
>>subversion/libsvn_wc/update_editor.c:1593: warning: `rev_str' might be
>>used uninitialized in this function
>
> Yes, I know about that one, it's interesting. It is unitialised, but
> only when it occurs after a NULL in a variable length argument list.
> So the unitialised value never gets used.

Since NULL as an argument list terminator is just a convention used by that particular function and some others, not a language-defined thing, it is understandable that the compiler doesn't know that the value is being ignored. (And it does say "might be used", but then a warning is a warning - it doesn't go away just because we know that it isn't ACTUALLY being used.)

Passing extra arguments after the valid arguments to a varargs function strikes me as poor style, but then making a duplicate of the function call with its first eight arguments is a bit uncomfortable as well. So I'm torn between just adding an "= NULL" initialiser and rewriting it something like:

  if (copyfrom_url)
    {
      const char *rev_str;

      assert (SVN_IS_VALID_REVNUM (copyfrom_rev));
      rev_str = apr_psprintf (pool, "%" SVN_REVNUM_T_FMT, copyfrom_rev);

      svn_xml_make_open_tag
        (&log_accum, pool, svn_xml_self_closing, SVN_WC__LOG_MODIFY_ENTRY,
         SVN_WC__LOG_ATTR_NAME, base_name,
         SVN_WC__ENTRY_ATTR_SCHEDULE, SVN_WC__ENTRY_VALUE_ADD,
         SVN_WC__ENTRY_ATTR_COPYFROM_URL, copyfrom_url,
         SVN_WC__ENTRY_ATTR_COPYFROM_REV, rev_str,
         SVN_WC__ENTRY_ATTR_COPIED, "true",
         NULL);
    }
  else
    {
      svn_xml_make_open_tag
        (&log_accum, pool, svn_xml_self_closing, SVN_WC__LOG_MODIFY_ENTRY,
         SVN_WC__LOG_ATTR_NAME, base_name,
         SVN_WC__ENTRY_ATTR_SCHEDULE, SVN_WC__ENTRY_VALUE_ADD,
         NULL);
    }

Not that it's anything to do with me ... I'm just butting in to your conversation.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 25 01:15:35 2003