Taylor Blau <me@xxxxxxxxxxxx> writes:
> Here's the (gross) script I wrote up to check:
>
> git grep -l -e '[^_]xstrdup(' -e 'strbuf_[a-z0-9A-Z_]*(' \*.c |
> while read f
> do
> if ! gcc -I $(pwd) -E $f | grep -q 'struct strbuf {'
> then
> echo "==> $f NOT OK";
> fi
> done
I am a bit puzzled.
What does the above prove, more than what your regular compilation
that does not fail, tells us? Doesn't -E expand recursively, so for
the case of imap-send.c, with your usual configuration, wouldn't it
have grabbed "struct strbuf" via inclusion of <http.h> indirectly
anyway?
> Here's the list:
>
> ==> compat/fsmonitor/fsm-listen-darwin.c NOT OK
> ==> compat/mingw.c NOT OK
> ==> contrib/credential/osxkeychain/git-credential-osxkeychain.c NOT OK
> ==> pager.c NOT OK
> ==> refs/iterator.c NOT OK
> ==> refs/ref-cache.c NOT OK
> ==> string-list.c NOT OK
> ==> t/helper/test-mktemp.c NOT OK
>
> The ones in compat are OK to ignore since they both fail to compile on
> my non-Windows machine (I am missing the `<dispatch/dispatch.h>` and
> `<windows.h>` headers, respectively).
>
> The one in contrib is fine to ignore, since it has its own definition of
> xstrdup().
>
> pager.c is OK, since it only needs xstrdup(), not any other parts of the
> strbuf API. It gets a declaration of xstrdup() from git-compat-util.h
> refs/iterator.c, refs/ref-cache.c, string-list.c, and
> t/helper/test-mktemp.c are all OK for the same reason.
>
> So I think that this is the only spot we need to worry about.
