| Message ID | xmqqh6scur3r.fsf_-_@gitster.g (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | run-command.c: need alloc.h for our own at-exit handler emulation | expand |
On Tuesday, May 16, 2023 1:24 PM, Junio C Hamano wrote: >Recent header file shuffling missed this old user of ALLOC_GROW() that was inside >"#ifdef NO_PTHREADS' section and forgot to include the new file, alloc.h, that defines >the macro. > >Signed-off-by: Junio C Hamano <gitster@pobox.com> > >--- > run-command.c | 1 + > 1 file changed, 1 insertion(+) > >diff --git c/run-command.c w/run-command.c index d4247d5fcc..1affea48af 100644 >--- c/run-command.c >+++ w/run-command.c >@@ -1073,6 +1073,7 @@ static void NORETURN async_exit(int code) } > > #else >+#include <alloc.h> > > static struct { > void (**handlers)(void); Thanks gents. Regards, Randall
On Tue, May 16, 2023 at 10:24:24AM -0700, Junio C Hamano wrote: > Recent header file shuffling missed this old user of ALLOC_GROW() > that was inside "#ifdef NO_PTHREADS' section and forgot to include > the new file, alloc.h, that defines the macro. Heh. I wrote an identical patch before lunch (which I just came back from). Feel free to queue either, I honestly do not care which as long as the bug is fixed :-). https://lore.kernel.org/git/db403de74da839084165f11dab05d71484457c6f.1684259780.git.me@ttaylorr.com/ Thanks, Taylor
On Tue, May 16, 2023 at 01:57:50PM -0400, Taylor Blau wrote: > On Tue, May 16, 2023 at 10:24:24AM -0700, Junio C Hamano wrote: > > Recent header file shuffling missed this old user of ALLOC_GROW() > > that was inside "#ifdef NO_PTHREADS' section and forgot to include > > the new file, alloc.h, that defines the macro. > > Heh. I wrote an identical patch before lunch (which I just came back > from). Feel free to queue either, I honestly do not care which as long > as the bug is fixed :-). > > https://lore.kernel.org/git/db403de74da839084165f11dab05d71484457c6f.1684259780.git.me@ttaylorr.com/ OK, having now read both completely, I would say I have a vague preference for my version since it keeps the include at the top and unconditional, and has slightly more information in the patch message. But I do not prefer it so much over yours that I would be sad if you had already queued yours and didn't want to bother shuffling it around. Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: > OK, having now read both completely, I would say I have a vague > preference for my version since it keeps the include at the top and > unconditional, and has slightly more information in the patch message. > > But I do not prefer it so much over yours that I would be sad if you had > already queued yours and didn't want to bother shuffling it around. I do not have much preference between the two, either. Both lack one important description that we are reasonably confident that this breakage is limited to run-command.c and no other files. Thanks.
On Tue, May 16, 2023 at 11:44:36AM -0700, Junio C Hamano wrote: > Taylor Blau <me@ttaylorr.com> writes: > > > OK, having now read both completely, I would say I have a vague > > preference for my version since it keeps the include at the top and > > unconditional, and has slightly more information in the patch message. > > > > But I do not prefer it so much over yours that I would be sad if you had > > already queued yours and didn't want to bother shuffling it around. > > I do not have much preference between the two, either. Both lack > one important description that we are reasonably confident that this > breakage is limited to run-command.c and no other files. I believe that mine does: (Everything else compiles fine when NO_PTHREADS is defined, so this is the only spot that needs fixing). Thanks, Taylor
Taylor Blau <me@ttaylorr.com> writes: > On Tue, May 16, 2023 at 11:44:36AM -0700, Junio C Hamano wrote: >> Taylor Blau <me@ttaylorr.com> writes: >> >> > OK, having now read both completely, I would say I have a vague >> > preference for my version since it keeps the include at the top and >> > unconditional, and has slightly more information in the patch message. >> > >> > But I do not prefer it so much over yours that I would be sad if you had >> > already queued yours and didn't want to bother shuffling it around. >> >> I do not have much preference between the two, either. Both lack >> one important description that we are reasonably confident that this >> breakage is limited to run-command.c and no other files. > > I believe that mine does: > > (Everything else compiles fine when NO_PTHREADS is defined, so this is > the only spot that needs fixing). Not quite. Who says NO_PTHREADS is the only conditional that may hide use of ALLOC_GROW()?
diff --git c/run-command.c w/run-command.c index d4247d5fcc..1affea48af 100644 --- c/run-command.c +++ w/run-command.c @@ -1073,6 +1073,7 @@ static void NORETURN async_exit(int code) } #else +#include <alloc.h> static struct { void (**handlers)(void);
Recent header file shuffling missed this old user of ALLOC_GROW() that was inside "#ifdef NO_PTHREADS' section and forgot to include the new file, alloc.h, that defines the macro. Signed-off-by: Junio C Hamano <gitster@pobox.com> --- run-command.c | 1 + 1 file changed, 1 insertion(+)