| Message ID | 20181027071003.1347-1-pclouds@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Reduce #ifdef NO_PTHREADS | expand |
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. Some of the bits in run-command.c can probably be converted, but all of the "struct async" bits can't ever be. Because there the fallback is not "OK, let's just run a single thread" but a whole separate forking mechanism. -Peff
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-pclouds@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
On Sat, Oct 27, 2018 at 10:13 AM Jeff King <peff@peff.net> wrote: > > 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-pclouds@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 couldn't reproduce it with gcc 8.2.0 on gentoo (I tried all optimization levels just in case). I agree the warning is wrong. But I will initialize copy_len anyway to avoid this.