| Message ID | 20181020070859.48172-1-carenas@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | builtin/receive-pack: dead initializer for retval in check_nonce | expand |
On Sat, Oct 20, 2018 at 12:08:59AM -0700, Carlo Marcelo Arenas Belón wrote: > NONCE_BAD is explicitly set when needed with the fallback > instead as NONCE_SLOP > > Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> > --- > builtin/receive-pack.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c > index 95740f4f0e..ecce3d4043 100644 > --- a/builtin/receive-pack.c > +++ b/builtin/receive-pack.c > @@ -507,7 +507,7 @@ static const char *check_nonce(const char *buf, size_t len) > char *nonce = find_header(buf, len, "nonce", NULL); > timestamp_t stamp, ostamp; > char *bohmac, *expect = NULL; > - const char *retval = NONCE_BAD; > + const char *retval; > > if (!nonce) { > retval = NONCE_MISSING; Thanks for the patch. The motivation feels a little bit weak, at least to me. Initializing a variable to "BAD" in the beginning can be a good thing for two reasons: - There is a complex if-elseif chain, which should set retval in any case, this is at least what I expect taking a very quick look at the code: const char *retval = NONCE_BAD; if (!nonce) { retval = NONCE_MISSING; goto leave; } else if (!push_cert_nonce) { retval = NONCE_UNSOLICITED; goto leave; } else if (!strcmp(push_cert_nonce, nonce)) { retval = NONCE_OK; goto leave; } # And here I started to wonder if we should have an else or not. # Having retval NONCE_BAD set to NONCE:BAD in the beginning makes # it clear, that we are save without the else. # As an alternative, we could have coded like this: const char *retval; if (!nonce) { retval = NONCE_MISSING; goto leave; } else if (!push_cert_nonce) { retval = NONCE_UNSOLICITED; goto leave; } else if (!strcmp(push_cert_nonce, nonce)) { retval = NONCE_OK; goto leave; } else { /* Set to BAD, until we know better further down */ retval = NONCE_BAD; } # The second reason is that some compilers don't understand this complex # stuff either, and through out a warning, like # "retval may be uninitialized" or something in that style. # This is very compiler dependent. So yes, the current code may seem to be over-eager and ask for optimization, but we don't gain more that a couple of nano-seconds or so. The good thing is that we have the code a little bit more robust, when changes are done in the future.
On Sat, Oct 20, 2018 at 9:45 AM Torsten Bögershausen <tboegi@web.de> wrote: > > The motivation feels a little bit weak, at least to me. I have to admit, I was sitting on this patch for a while for the same reason but I should had made a more compelling commit message either way and will definitely fix that with v2. the point was that setting the variable to BAD originally seemed to be legacy from the original version of the code, specially considering that the newer version was setting it to SLOB at the last "else". the code was written in a way that would make all those assignments to BAD explicit (even if it wasn't needed, since it was initialized to that value) and so it would seem better IMHO to use the compiler to remind us that this variable MUST be set to the right value than setting the most likely value by default. > Initializing a variable to "BAD" in the beginning can be a good thing > for two reasons: > - There is a complex if-elseif chain, which should set retval > in any case, this is at least what I expect taking a very quick look at the > code: > const char *retval = NONCE_BAD; > > if (!nonce) { > retval = NONCE_MISSING; > goto leave; > } else if (!push_cert_nonce) { > retval = NONCE_UNSOLICITED; > goto leave; > } else if (!strcmp(push_cert_nonce, nonce)) { > retval = NONCE_OK; > goto leave; > } > # And here I started to wonder if we should have an else or not. > # Having retval NONCE_BAD set to NONCE:BAD in the beginning makes > # it clear, that we are save without the else. > # As an alternative, we could have coded like this: > > const char *retval; > > if (!nonce) { > retval = NONCE_MISSING; > goto leave; > } else if (!push_cert_nonce) { > retval = NONCE_UNSOLICITED; > goto leave; > } else if (!strcmp(push_cert_nonce, nonce)) { > retval = NONCE_OK; > goto leave; > } else { > /* Set to BAD, until we know better further down */ > retval = NONCE_BAD; > } > > # The second reason is that some compilers don't understand this complex > # stuff either, and through out a warning, like > # "retval may be uninitialized" or something in that style. > # This is very compiler dependent. FWIW I did test with gcc (from 4.9 to 8) and clang 7 (linux) and 10 (macos) and didn't trigger any warning. > So yes, the current code may seem to be over-eager and ask for optimization, > but we don't gain more that a couple of nano-seconds or so. > The good thing is that we have the code a little bit more robust, when changes are done > in the future. on the other hand was able to trigger a warning if the code was changed so some path will leave retval uninitialized (after adding -Wmaybe-uninitialized to gcc and -Wsometimes-uninitialized to clang) since there was no longer a default of BAD (probably incorrectly) that would be returned in case setting retval to the right value was forgotten. Carlo
Torsten Bögershausen <tboegi@web.de> writes: > Initializing a variable to "BAD" in the beginning can be a good thing > for two reasons: > - There is a complex if-elseif chain, which should set retval > in any case, this is at least what I expect taking a very quick look at the > code: > ... > # The second reason is that some compilers don't understand this complex > # stuff either, and through out a warning, like > # "retval may be uninitialized" or something in that style. > # This is very compiler dependent. And to help humans that unless some if/else chain explicitly says it is OK, the caller receives BAD by default. In other words, it is being defensive. At least that was the reasoning behind the original code that did not support SLOP. > So yes, the current code may seem to be over-eager and ask for > optimization, but we don't gain more that a couple of nano-seconds > or so. The good thing is that we have the code a little bit more > robust, when changes are done in the future. True.
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index 95740f4f0e..ecce3d4043 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -507,7 +507,7 @@ static const char *check_nonce(const char *buf, size_t len) char *nonce = find_header(buf, len, "nonce", NULL); timestamp_t stamp, ostamp; char *bohmac, *expect = NULL; - const char *retval = NONCE_BAD; + const char *retval; if (!nonce) { retval = NONCE_MISSING;
NONCE_BAD is explicitly set when needed with the fallback instead as NONCE_SLOP Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> --- builtin/receive-pack.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)