Re: More error leaks

On 1/19/06, Julian Foad <julianfoad@btopenworld.com> wrote:
> By putting "__attribute__((warn_unused_result))" on each declaration of a
> function that returns "svn_error_t *", I found the following errors being leaked:
>
> subversion/libsvn_fs_fs/fs_fs.c: In function 'svn_fs_fs__set_entry':
> subversion/libsvn_fs_fs/fs_fs.c:2773: return value of 'svn_stream_printf'
> subversion/libsvn_fs_fs/fs_fs.c:2790: return value of 'svn_stream_printf'
> subversion/libsvn_fs_fs/fs_fs.c: In function 'svn_fs_fs__create':
> subversion/libsvn_fs_fs/fs_fs.c:4007: return value of 'svn_fs_fs__set_uuid'
> --
> subversion/libsvn_repos/commit.c: In function 'check_authz':
> subversion/libsvn_repos/commit.c:148: return value of function
> subversion/libsvn_repos/commit.c: In function 'svn_repos_get_commit_editor4':
> subversion/libsvn_repos/commit.c:798: return value of function
> --
> subversion/libsvn_repos/dump.c: In function 'dump_node':
> subversion/libsvn_repos/dump.c:414: return value of 'svn_stream_printf'
> --
> subversion/libsvn_client/locking_commands.c: In function 'svn_client_lock':
> subversion/libsvn_client/locking_commands.c:457: return value of 'svn_wc_adm_close'
> subversion/libsvn_client/locking_commands.c: In function 'svn_client_unlock':
> subversion/libsvn_client/locking_commands.c:514: return value of 'svn_wc_adm_close'
> --
> subversion/libsvn_diff/diff_file.c: In function
> 'svn_diff__file_output_unified_default_hdr':
> subversion/libsvn_diff/diff_file.c:894: return value of 'svn_io_stat'
> --
> subversion/svn/main.c: In function 'main':
> subversion/svn/main.c:825: return value of 'svn_cl__help'
> subversion/svn/main.c:844: return value of 'svn_cl__help'
> subversion/svn/main.c:1147: return value of 'svn_cl__help'
> subversion/svn/main.c:1166: return value of 'svn_cl__help'
> --
> subversion/svn/util.c: In function 'svn_cl__get_log_message':
> subversion/svn/util.c:631: return value of 'svn_cmdline_prompt_user'
> --
> subversion/svnadmin/main.c: In function 'main':
> subversion/svnadmin/main.c:1171: return value of 'subcommand_help'
> subversion/svnadmin/main.c:1196: return value of 'subcommand_help'
> subversion/svnadmin/main.c:1294: return value of 'subcommand_help'
> subversion/svnadmin/main.c:1317: return value of 'subcommand_help'
> subversion/svnadmin/main.c:1335: return value of 'subcommand_help'
> --
> subversion/svndumpfilter/main.c: In function 'main':
> subversion/svndumpfilter/main.c:1114: return value of 'subcommand_help'
> subversion/svndumpfilter/main.c:1137: return value of 'subcommand_help'
> subversion/svndumpfilter/main.c:1168: return value of 'subcommand_help'
> subversion/svndumpfilter/main.c:1190: return value of 'subcommand_help'
> subversion/svndumpfilter/main.c:1209: return value of 'subcommand_help'
> --
> subversion/svnlook/main.c: In function 'main':
> subversion/svnlook/main.c:2020: return value of 'subcommand_help'
> subversion/svnlook/main.c:2042: return value of 'subcommand_help'
> subversion/svnlook/main.c:2112: return value of 'subcommand_help'
> subversion/svnlook/main.c:2142: return value of 'subcommand_help'
> subversion/svnlook/main.c:2161: return value of 'subcommand_help'
> subversion/svnlook/main.c:2193: return value of 'subcommand_help'
> --
> subversion/svnsync/main.c: In function 'main':
> subversion/svnsync/main.c:1110: return value of 'help'
> subversion/svnsync/main.c:1128: return value of 'help'
> subversion/svnsync/main.c:1173: return value of 'help'
> subversion/svnsync/main.c:1187: return value of 'help'
> subversion/svnsync/main.c:1198: return value of 'help'
> --
> subversion/tests/libsvn_repos/repos-test.c: In function 'commit_editor_authz':
> subversion/tests/libsvn_repos/repos-test.c:1564: return value of function
>
>
> Most of them probably just need "SVN_ERR", but some may be more complex. If
> someone is willing to take a look at them and fix all or most of them, that
> would be great.
>
> Of course the other question raised is: do we want to consider using such
> attributes as a matter of course? Obviously only if it is done neatly and in a
> way that doesn't interfere with other compilers; macros can help to achieve
> that. I'll have a bit more of a think about that.

Nice analysis, Julian. I agree with your conclusion. First, we need to
fix places where we ignore errors. Next, if we can find a neat and
clean way to add __attribute__((warn_unused_result)) to declarations
of functions which return errors, that would be great.

Cheers,

David

--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org