On 22/01/2019 07:23, Jeff King wrote: > On Fri, Jan 18, 2019 at 01:41:08AM +0000, Ramsay Jones wrote: > >> I don't do this "from time to time", but *every* build on all >> platforms! :-D >> >> As I have mentioned before, I run the script on 'master', 'next' >> and 'pu', but I don't look at the results for 'master', I simply >> look at the diffs master->next and next->pu. > > Ah, ok, that explains it, then. As you noted, these made it straight to > master because of the security embargo. > > Thanks for satisfying my curiosity (and for running your script!). > > I do wonder if you might be better off comparing master@{1} to master to > see if anything new appears (since I assume the whole point is ignoring > historical false positives, and just looking at patches under active > development). Hmm, well it's not so much 'historical false positives' as 'oh dear, they managed to get through' (along with a promise to myself to get around to tidying up the symbols in master - yet again!). ;-) I try to make people aware of the issues, when they appear in 'pu', so that we have a chance not to make things worse. However, it is never as simple as 'this symbol is not used/local to this file, please fix' (despite what it looks like, I don't like to annoy contributors with those emails :-D ). Many recent large changes have been split into several series with earlier series introducing symbols which 'will be used later'. Sometimes later never comes. ;-) Recently, Brian's 'bc/sha-256' branch merged into 'next', so now: $ diff sc nsc 37a38,39 > hex.o - hash_to_hex > hex.o - hash_to_hex_algop_r 74a77,78 > sha1-file.o - hash_algo_by_id > sha1-file.o - hash_algo_by_name $ Brian has already indicated [1] that future patches will add uses for these symbols. [1] https://public-inbox.org/git/20181114021118.GN890086@xxxxxxxxxxxxxxxxxxxxxxxxxx/ [Just to be clear, my script only notes symbols that are not referenced outside of the object file which contains its definition - so that includes file-local and unused symbols]. There are currently 90 symbols in the 'sc' file, some of which should be added to the outdated 'skip list'. Just FYI, the file which has the most hits is: $ cut -f1 sc | sort | uniq -c | sort -rn 26 config.o 6 sha1dc/sha1.o 6 refs.o 6 json-writer.o 3 utf8.o 3 sha1-file.o 3 revision.o 3 refs/ref-cache.o 2 vcs-svn/fast_export.o 2 refs/packed-backend.o 2 path.o 2 parse-options.o 2 graph.o 2 attr.o 1 worktree.o 1 trace.o 1 tmp-objdir.o 1 tempfile.o 1 strbuf.o 1 serve.o 1 sequencer.o 1 refspec.o 1 refs/iterator.o 1 read-cache.o 1 pkt-line.o 1 oidmap.o 1 line-log.o 1 ident.o 1 hex.o 1 gettext.o 1 fuzz-pack-idx.o 1 fuzz-pack-headers.o 1 editor.o 1 credential.o 1 convert.o 1 builtin/pack-objects.o $ ... and the symbols in that file: $ grep config.o sc config.o - git_config_copy_section_in_file config.o - git_config_from_file_with_options config.o - git_config_from_parameters config.o - git_config_get_bool_or_int config.o - git_config_get_maybe_bool config.o - git_config_get_pathname config.o - git_config_include config.o - git_config_key_is_valid config.o - git_configset_get_bool config.o - git_configset_get_bool_or_int config.o - git_configset_get_int config.o - git_configset_get_maybe_bool config.o - git_configset_get_pathname config.o - git_configset_get_string config.o - git_configset_get_string_const config.o - git_configset_get_ulong config.o - git_config_set_multivar_in_file config.o - git_config_system config.o - git_die_config_linenr config.o - repo_config config.o - repo_config_get_bool_or_int config.o - repo_config_get_int config.o - repo_config_get_maybe_bool config.o - repo_config_get_pathname config.o - repo_config_get_ulong config.o - repo_config_get_value $ ATB, Ramsay Jones