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.gn890...@genre.crustytoothpaste.net/
[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
