On Sat, Oct 20, 2018 at 9:45 AM Torsten Bögershausen <tboegi@xxxxxx> 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
