[PATCH] builtin/receive-pack: dead initializer for retval in check_nonce

[PATCH] builtin/receive-pack: dead initializer for retval in check_nonce

[Carlo Marcelo Arenas Belón]

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;
-- 
2.19.1

Re: [PATCH] builtin/receive-pack: dead initializer for retval in check_nonce

[Torsten Bögershausen]

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.

Re: [PATCH] builtin/receive-pack: dead initializer for retval in check_nonce

[Carlo Arenas]

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

Re: [PATCH] builtin/receive-pack: dead initializer for retval in check_nonce

[Junio C Hamano]

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.