You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2006/01/26 00:35:33 UTC
Still using some of our deprecated functions
We are still using several of our own deprecated functions and types.
I added "__attribute__((deprecated))" to all of our "@deprecated" functions and
types, and this is what I found. I edited the result by hand to remove
warnings for uses within a deprecated function, because such uses are fine.
Because of the hand editing I don't guarantee that all the uses listed here are
wrong or that all wrong uses are listed.
subversion/libsvn_subr/config.c:0654: svn_config_enumerate_sections
subversion/libsvn_subr/config.c:0655: svn_config_section_enumerator_t
subversion/libsvn_subr/config.c:0660: svn_config_section_enumerator_t
subversion/libsvn_subr/config.c:0719: svn_config_enumerator_t
subversion/libsvn_repos/dump.c:1038: svn_repos_replay
subversion/svnlook/main.c:0386: svn_repos_replay
subversion/tests/libsvn_repos/repos-test.c:0408: svn_repos_replay
subversion/libsvn_repos/load.c:0087: svn_repos_parser_fns_t
subversion/libsvn_repos/load.c:0733: svn_repos_parser_fns_t
subversion/libsvn_repos/load.c:1247: svn_repos_parser_fns_t
subversion/libsvn_repos/load.c:1252: svn_repos_get_fs_build_parser
subversion/libsvn_repos/load.c:1265: svn_repos_parser_fns_t
subversion/libsvn_repos/load.c:1274: svn_repos_parser_fns_t
subversion/svndumpfilter/main.c:0740: svn_repos_parser_fns_t
subversion/libsvn_client/add.c:0551: log_msg_func
subversion/libsvn_client/commit.c:0648: log_msg_func
subversion/libsvn_client/commit.c:1459: log_msg_func
subversion/libsvn_client/commit_util.c:0608: svn_wc_walk_entries
subversion/libsvn_client/commit_util.c:1630: log_msg_func
subversion/libsvn_client/commit_util.c:1634: svn_client_commit_item_t
subversion/libsvn_client/commit_util.c:1656: svn_client_commit_item_t
subversion/libsvn_client/commit_util.c:1660: log_msg_func
subversion/libsvn_client/commit_util.c:1661: log_msg_baton
subversion/libsvn_client/copy.c:0423: log_msg_func
subversion/libsvn_client/copy.c:0650: log_msg_func
subversion/libsvn_client/delete.c:0139: log_msg_func
subversion/libsvn_client/diff.c:1748: svn_ra_do_diff
subversion/libsvn_client/diff.c:2181: svn_ra_do_diff
subversion/libsvn_client/ra.c:0069: svn_io_open_unique_file
subversion/libsvn_wc/adm_ops.c:0511: svn_wc_process_committed
subversion/libsvn_wc/adm_ops.c:0777: svn_io_get_dirents
subversion/libsvn_wc/status.c:0798: svn_io_get_dirents
subversion/svnlook/main.c:1154: svn_subst_translate_cstring
subversion/svnlook/main.c:1502: svn_repos_history
subversion/svnsync/main.c:0244: svn_io_open_unique_file
subversion/mod_dav_svn/repos.c:2382: svn_io_get_dirents
subversion/tests/libsvn_diff/diff-diff3-test.c:0228: svn_diff_file_output_unified
subversion/tests/libsvn_fs/fs-test.c:0135: svn_fs_begin_txn
... and many more instances in this and other tests.
subversion/tests/libsvn_ra_local/ra-local-test.c:0078: svn_ra_plugin_t
subversion/tests/libsvn_ra_local/ra-local-test.c:0087: svn_ra_callbacks_t
subversion/tests/libsvn_ra_local/ra-local-test.c:0090: svn_ra_init_ra_libs
subversion/tests/libsvn_ra_local/ra-local-test.c:0093: svn_ra_get_ra_library
subversion/tests/libsvn_ra_local/ra-local-test.c:0115: svn_ra_plugin_t
subversion/tests/libsvn_ra_local/ra-local-test.c:0137: svn_ra_plugin_t
subversion/tests/libsvn_repos/repos-test.c:0674: svn_repos_history
subversion/tests/libsvn_fs_base/changes-test.c:0112: svn_fs_parse_id
... and many more instances in this file.
subversion/tests/libsvn_fs_base/fs-base-test.c:0096: svn_fs_open_berkeley
subversion/tests/libsvn_fs_base/fs-base-test.c:0099: svn_fs_set_berkeley_errcall
In most cases the solution is to upgrade the code to use a newer,
non-deprecated alternative. In some cases that might not be so. In the tests
we may decide that calling deprecated functions is OK.
Any volunteers to tackle some of these? I suggest doing so one small logical
group at a time. For each deprecated identifier that you tackle, please search
for and check all remaining uses, to be sure.
Since GCC is not filtering out warnings of deprecated use within deprecated
functions, this warning is not one that we can make good use of on a regular,
automatic basis.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop using deprecated functions [was: Still using some
of our deprecated functions]
Posted by Julian Foad <ju...@btopenworld.com>.
Peter N. Lundblad wrote:
> On Mon, 13 Feb 2006, Julian Foad wrote:
>>
>>>subversion/libsvn_wc/adm_ops.c:0511: svn_wc_process_committed
>>
>>What the heck? This is the "2" version recursing via the original version,
>>thus losing the "remove_lock" parameter on recursion. Is this a bug or is it
>>the desired behaviour?
>
> Well, it could call the non-deprecated version, but it should still set
> remove_lock to FALSE when recursing, since when we're removing locks in
> commit, each path with a lock will be a commit item.
OK, I don't follow the explanation but as you're happy with it I'll include
that change in this patch.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Stop using deprecated functions [was: Still using some
of our deprecated functions]
Posted by "Peter N. Lundblad" <pe...@famlundblad.se>.
On Mon, 13 Feb 2006, Julian Foad wrote:
> Julian Foad wrote:
> > subversion/libsvn_wc/adm_ops.c:0511: svn_wc_process_committed
>
> What the heck? This is the "2" version recursing via the original version,
> thus losing the "remove_lock" parameter on recursion. Is this a bug or is it
> the desired behaviour?
>
Well, it could call the non-deprecated version, but it should still set
remove_lock to FALSE when recursing, since when we're removing locks in
commit, each path with a lock will be a commit item.
Thanks for this cleaning work,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
[PATCH] Stop using deprecated functions [was: Still using some of
our deprecated functions]
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> We are still using several of our own deprecated functions and types.
[...]
> subversion/libsvn_subr/config.c:0654: svn_config_enumerate_sections
> subversion/libsvn_subr/config.c:0655: svn_config_section_enumerator_t
> subversion/libsvn_subr/config.c:0660: svn_config_section_enumerator_t
> subversion/libsvn_subr/config.c:0719: svn_config_enumerator_t
These are fine: used only in compatibility code.
> subversion/libsvn_repos/dump.c:1038: svn_repos_replay
> subversion/svnlook/main.c:0386: svn_repos_replay
> subversion/tests/libsvn_repos/repos-test.c:0408: svn_repos_replay
Upgraded. (By this I mean: call the new function, just passing default or
backward-compatible values for any new parameters.)
> subversion/libsvn_repos/load.c:0087: svn_repos_parser_fns_t
> subversion/libsvn_repos/load.c:0733: svn_repos_parser_fns_t
> subversion/libsvn_repos/load.c:1247: svn_repos_parser_fns_t
> subversion/libsvn_repos/load.c:1252: svn_repos_get_fs_build_parser
> subversion/libsvn_repos/load.c:1265: svn_repos_parser_fns_t
> subversion/libsvn_repos/load.c:1274: svn_repos_parser_fns_t
These are fine: used only in compatibility code. (The new function is calling
the old one. Generally it should be done the other way round for efficiency
and maintainability, but this isn't frequently called so no big deal.)
> subversion/svndumpfilter/main.c:0740: svn_repos_parser_fns_t
Upgraded.
> subversion/libsvn_client/commit_util.c:0608: svn_wc_walk_entries
Upgraded, adding cancellation to this part of the walk.
> subversion/libsvn_client/diff.c:1748: svn_ra_do_diff
> subversion/libsvn_client/diff.c:2181: svn_ra_do_diff
> subversion/libsvn_client/ra.c:0069: svn_io_open_unique_file
Upgraded.
> subversion/libsvn_wc/adm_ops.c:0511: svn_wc_process_committed
What the heck? This is the "2" version recursing via the original version,
thus losing the "remove_lock" parameter on recursion. Is this a bug or is it
the desired behaviour?
I'm not touching that yet.
> subversion/libsvn_wc/adm_ops.c:0777: svn_io_get_dirents
Upgraded.
> subversion/libsvn_wc/status.c:0798: svn_io_get_dirents
Upgraded. Yikes - this was calling the old function and yet using the new
extended result type; the implementation just happened to be providing it.
> subversion/svnlook/main.c:1154: svn_subst_translate_cstring
> subversion/svnlook/main.c:1502: svn_repos_history
> subversion/svnsync/main.c:0244: svn_io_open_unique_file
> subversion/mod_dav_svn/repos.c:2382: svn_io_get_dirents
Upgraded.
The rest of the calls to deprecated functions were in the tests. I'd say we
needn't upgrade them until we are prepared to make them test some of the new
features of the new APIs. Until then, they might as well ensure that the old
versions continue to work.
Could someone cast an eye over this please?
- Julian
Re: Still using some of our deprecated functions
Posted by Julian Foad <ju...@btopenworld.com>.
Julian Foad wrote:
> We are still using several of our own deprecated functions and types.
Here are some more that I forgot to include in the list.
svn_fs_new
svn_repos_parse_dumpstream
svn_commit_callback_t (?)
svn_stream_from_aprfile
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Still using some of our deprecated functions
Posted by Ivan Zhakov <ch...@gmail.com>.
On 1/26/06, Julian Foad <ju...@btopenworld.com> wrote:
> We are still using several of our own deprecated functions and types.
>
> I added "__attribute__((deprecated))" to all of our "@deprecated" functions and
> types, and this is what I found. I edited the result by hand to remove
> warnings for uses within a deprecated function, because such uses are fine.
> Because of the hand editing I don't guarantee that all the uses listed here are
> wrong or that all wrong uses are listed.
>
[..]
> subversion/libsvn_client/add.c:0551: log_msg_func
> subversion/libsvn_client/commit.c:0648: log_msg_func
> subversion/libsvn_client/commit.c:1459: log_msg_func
> subversion/libsvn_client/commit_util.c:1630: log_msg_func
> subversion/libsvn_client/commit_util.c:1634: svn_client_commit_item_t
> subversion/libsvn_client/commit_util.c:1656: svn_client_commit_item_t
> subversion/libsvn_client/commit_util.c:1660: log_msg_func
> subversion/libsvn_client/commit_util.c:1661: log_msg_baton
> subversion/libsvn_client/copy.c:0423: log_msg_func
> subversion/libsvn_client/copy.c:0650: log_msg_func
> subversion/libsvn_client/delete.c:0139: log_msg_func
This is valid stuff. Deprecated svn_client_commit_item_t used for
calling deprecated callback log_msg_func/log_msg_baton.
--
Ivan Zhakov