# [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning 8 messages from 2010-12-04 to 2010-12-10. Participants: Ramsay Jones, Jonathan Nieder, Junio C Hamano, Erik Faye-Lund, Sebastian Schuberth. Thread: https://gitlist.dev/t/25957 ## Ramsay Jones, 2010-12-04 19:12 Subject: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: <4CFA92A2.4030801@ramsay1.demon.co.uk> URL: https://gitlist.dev/e/4CFA92A2.4030801%40ramsay1.demon.co.uk ``` The msvc compiler thinks that a variable could be used while uninitialised and issues the following warning: ...\git\wt-status.c(152) : warning C4700: uninitialized local \ variable 'status' used In order to suppress the warning, we simply initialise the variable to zero. Signed-off-by: Ramsay Jones --- wt-status.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/wt-status.c b/wt-status.c index d9f3d9f..9b4b5bf 100644 --- a/wt-status.c +++ b/wt-status.c @@ -149,7 +149,7 @@ static void wt_status_print_change_data(struct wt_status *s, { struct wt_status_change_data *d = it->util; const char *c = color(change_type, s); - int status = status; + int status = 0; char *one_name; char *two_name; const char *one, *two; -- 1.7.3 ``` ## Jonathan Nieder, 2010-12-04 20:52 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: <20101204205206.GB3170@burratino> URL: https://gitlist.dev/e/20101204205206.GB3170%40burratino In-Reply-To: <4CFA92A2.4030801@ramsay1.demon.co.uk> ``` Ramsay Jones wrote: > --- a/wt-status.c > +++ b/wt-status.c > @@ -149,7 +149,7 @@ static void wt_status_print_change_data(struct wt_status *s, > { > struct wt_status_change_data *d = it->util; > const char *c = color(change_type, s); > - int status = status; > + int status = 0; Just for the record (I assume you are already aware of this): http://thread.gmane.org/gmane.comp.version-control.git/133278/focus=133422 http://thread.gmane.org/gmane.comp.version-control.git/124676/focus=124803 I personally feel lukewarm about this kind of change. Is it possible to suppress this warning from msvc? ``` ## Ramsay Jones, 2010-12-09 18:17 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: <4D011D30.4070405@ramsay1.demon.co.uk> URL: https://gitlist.dev/e/4D011D30.4070405%40ramsay1.demon.co.uk In-Reply-To: <20101204205206.GB3170@burratino> ``` Jonathan Nieder wrote: > > Just for the record (I assume you are already aware of this): > > http://thread.gmane.org/gmane.comp.version-control.git/133278/focus=133422 > http://thread.gmane.org/gmane.comp.version-control.git/124676/focus=124803 Yes > I personally feel lukewarm about this kind of change. OK. Junio, could you please drop patches 5-14 from the series; the first four patches are the important ones and I'd rather they didn't get held up. Thanks! ATB, Ramsay Jones ``` ## Junio C Hamano, 2010-12-09 19:08 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: <7vmxoeg3wp.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vmxoeg3wp.fsf%40alter.siamese.dyndns.org In-Reply-To: <4D011D30.4070405@ramsay1.demon.co.uk> ``` Ramsay Jones writes: > Junio, could you please drop patches 5-14 from the series; the first four patches > are the important ones and I'd rather they didn't get held up. Thanks! Have these four patches been Acked by interested parties? I think I saw 1/N and 2/N acked by Erik and 4/N acked by SSchuberth and J6t, but any words on 3/N? Not that I deeply care nor have environment to test changes to [3/N], but I am wondering if these need conditional definition to futureproof (e.g. what happens when the header you are using the definition _I64_MIN from, or some other headers, started defining these constats?). ``` ## Erik Faye-Lund, 2010-12-09 19:46 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: URL: https://gitlist.dev/e/AANLkTi%3DSzDhoQnLeKUvWe7A6r-7MT-DTLuDGLprqid9X%40mail.gmail.com In-Reply-To: <7vmxoeg3wp.fsf@alter.siamese.dyndns.org> ``` On Thu, Dec 9, 2010 at 8:08 PM, Junio C Hamano wrote: > Ramsay Jones writes: > >> Junio, could you please drop patches 5-14 from the series; the first four patches >> are the important ones and I'd rather they didn't get held up. Thanks! > > Have these four patches been Acked by interested parties? > > I think I saw 1/N and 2/N acked by Erik and 4/N acked by SSchuberth and > J6t, but any words on 3/N? > > Not that I deeply care nor have environment to test changes to [3/N], but > I am wondering if these need conditional definition to futureproof (e.g. > what happens when the header you are using the definition _I64_MIN from, > or some other headers, started defining these constats?). I'm not sure if I follow this entirely. _I64_MIN is defined by limits.h on Windows, and limits.h has a header-guard (or "#pragma once" as Microsoft-code tends to prefer). Oh, right. You mean if someone else starts defining INTMAX_MAX etc? If someone includes an stdint/inttypes-implementation while including git-compat-util.h, we're going to have a boat-load of similar issues anyway. I think guarding them is something that's better left to when we encounter the problem (if ever). All in all, patch 1 though 4 looks good to me. And thanks to Ramsay for cleaning up my mess :) ``` ## Sebastian Schuberth, 2010-12-10 13:35 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: URL: https://gitlist.dev/e/AANLkTinty08S2vT9ZSVQW03yL5uzrmqW7k_Ozad-q-E2%40mail.gmail.com In-Reply-To: ``` On Thu, Dec 9, 2010 at 20:46, Erik Faye-Lund wrote: > On Thu, Dec 9, 2010 at 8:08 PM, Junio C Hamano wrote: >> Ramsay Jones writes: >> >>> Junio, could you please drop patches 5-14 from the series; the first four patches >>> are the important ones and I'd rather they didn't get held up. Thanks! >> >> Have these four patches been Acked by interested parties? >> >> I think I saw 1/N and 2/N acked by Erik and 4/N acked by SSchuberth and >> J6t, but any words on 3/N? >> >> Not that I deeply care nor have environment to test changes to [3/N], but >> I am wondering if these need conditional definition to futureproof (e.g. >> what happens when the header you are using the definition _I64_MIN from, >> or some other headers, started defining these constats?). > > I'm not sure if I follow this entirely. _I64_MIN is defined by > limits.h on Windows, and limits.h has a header-guard (or "#pragma > once" as Microsoft-code tends to prefer). > > Oh, right. You mean if someone else starts defining INTMAX_MAX etc? If > someone includes an stdint/inttypes-implementation while including > git-compat-util.h, we're going to have a boat-load of similar issues > anyway. I think guarding them is something that's better left to when > we encounter the problem (if ever). FYI: In contrast to previous versions, Visual Studio 2010 ships with a stdint.h header which defines INTMAX_MAX etc. However, that stdint.h is not included by limits.h (in fact, not by *any* other shipping header file, as it seems), so we should not run into any trouble even with VS2010. So I agree with Erik about patch 3/N: Acked-by: Sebastian Schuberth -- Sebastian Schuberth ``` ## Erik Faye-Lund, 2010-12-10 15:05 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: URL: https://gitlist.dev/e/AANLkTikE34sk_bsAZSmq-9MaV-RE%2BGCJgNszm2o2qHGD%40mail.gmail.com In-Reply-To: ``` On Fri, Dec 10, 2010 at 2:35 PM, Sebastian Schuberth wrote: > On Thu, Dec 9, 2010 at 20:46, Erik Faye-Lund wrote: > >> On Thu, Dec 9, 2010 at 8:08 PM, Junio C Hamano wrote: >>> Ramsay Jones writes: >>> >>>> Junio, could you please drop patches 5-14 from the series; the first four patches >>>> are the important ones and I'd rather they didn't get held up. Thanks! >>> >>> Have these four patches been Acked by interested parties? >>> >>> I think I saw 1/N and 2/N acked by Erik and 4/N acked by SSchuberth and >>> J6t, but any words on 3/N? >>> >>> Not that I deeply care nor have environment to test changes to [3/N], but >>> I am wondering if these need conditional definition to futureproof (e.g. >>> what happens when the header you are using the definition _I64_MIN from, >>> or some other headers, started defining these constats?). >> >> I'm not sure if I follow this entirely. _I64_MIN is defined by >> limits.h on Windows, and limits.h has a header-guard (or "#pragma >> once" as Microsoft-code tends to prefer). >> >> Oh, right. You mean if someone else starts defining INTMAX_MAX etc? If >> someone includes an stdint/inttypes-implementation while including >> git-compat-util.h, we're going to have a boat-load of similar issues >> anyway. I think guarding them is something that's better left to when >> we encounter the problem (if ever). > > FYI: In contrast to previous versions, Visual Studio 2010 ships with a > stdint.h header which defines INTMAX_MAX etc. However, that stdint.h > is not included by limits.h (in fact, not by *any* other shipping > header file, as it seems), so we should not run into any trouble even > with VS2010. > Very interesting, thanks. Did you try to compile Git on VS2010? This sounds like a reason for me to install VS2010 on one of my machines... :) ``` ## Sebastian Schuberth, 2010-12-10 15:43 Subject: Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning Message-ID: URL: https://gitlist.dev/e/AANLkTimXVXoY3tENBy1EzTF7Hg00WPpww6pCf-hF6aT9%40mail.gmail.com In-Reply-To: ``` On Fri, Dec 10, 2010 at 16:05, Erik Faye-Lund wrote: >> FYI: In contrast to previous versions, Visual Studio 2010 ships with a >> stdint.h header which defines INTMAX_MAX etc. However, that stdint.h >> is not included by limits.h (in fact, not by *any* other shipping >> header file, as it seems), so we should not run into any trouble even >> with VS2010. >> > > Very interesting, thanks. Did you try to compile Git on VS2010? This > sounds like a reason for me to install VS2010 on one of my machines... > :) I just gave it a quick try by just importing the VS2008 solution, and there seem to be some CRT related link problems, but these should be easy to resolve. I don't have the time right now to look any further into this, sorry. -- Sebastian Schuberth ```