On Sat, Oct 27, 2018 at 09:09:53AM +0200, Nguyễn Thái Ngọc Duy wrote:
> People seemed to support the idea of removing these #ifdef NO_PTHREADS [1]
> so this is a complete series. I left the #ifdef in run-command.c and
> transport-helper.c because those code looked complicated so perhaps we
> could clean them up later. Even these updated files could be updated
> more, I think, to reduce some code duplication, but I tried to keep
> the change here minimal.
>
> [1] https://public-inbox.org/git/20181018180522.17642-1-pclo...@gmail.com/
>
> Nguyễn Thái Ngọc Duy (10):
> thread-utils: macros to unconditionally compile pthreads API
> index-pack: remove #ifdef NO_PTHREADS
> name-hash.c: remove #ifdef NO_PTHREADS
> attr.c: remove #ifdef NO_PTHREADS
> send-pack.c: remove #ifdef NO_PTHREADS
> grep: remove #ifdef NO_PTHREADS
> preload-index.c: remove #ifdef NO_PTHREADS
> pack-objects: remove #ifdef NO_PTHREADS
> read-cache.c: remove #ifdef NO_PTHREADS
> Clean up pthread_create() error handling
Compiling with NO_PTHREADS=1, I get (with gcc 8.2.0):
read-cache.c: In function ‘do_read_index’:
read-cache.c:1820:4: error: ‘copy_len’ may be used uninitialized in this
function [-Werror=maybe-uninitialized]
memcpy(ce->name, previous_ce->name, copy_len);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
read-cache.c:1749:9: note: ‘copy_len’ was declared here
size_t copy_len;
which seems wrong to me. It's always tied to expand_name_field being
true. And curiously an earlier use doesn't trigger the warning. I wonder
if some kind of tricky pointer aliasing in the intervening code makes it
think that expand_name_field could change, but I sure don't see it.
I ran the tests under ASan/UBSan, since this series seems like it has a
good chance of accidentally causing issues there, but didn't come up
with any problems (except for the ones already fixed on pu by 8628ace269
(commit-reach: fix cast in compare_commits_by_gen(), 2018-10-01)).
-Peff
