a != b || a != c is always true, a cannot equal both b and c, so one of the two branches has to be true.

The negation you're looking for is !(a == b && a == c) or a != b && a != c

Edit: never mind, tired eyes should not review code.

I'm not sure I follow this bug report. All three names are constants, and they're equal, so I presume that vet is seeing the condition as a != b || a != b, or even as a != a. That is, the condition will always be false.

It's not that vet doesn't like conditions that are always true or false. I believe this check is to spot human error when writing repetitive boolean expressions.

You're right that a != b || a != c in general is a valid boolean, but I don't think vet would flag that condition if the names involved were variables with unknown values.

All three names are constants, and they're equal, so I presume that vet is seeing the condition as a != b || a != b, or even as a != a. That is, the condition will always be false.

... will be always false iff the three constants are equal. And that's the very point of the test.

If anyone later changes any of the {szKey,szVal,szBuf} constants, each of which tunes an independent thing, in a way such that they become not equal, the condition will become true and the init() will panic as desired because the code simplifications rely on that invariant. So the constants must remain the same or the code must be adjusted to handle them not being equal.

My quick 2c: This is a false positive. But it’s the first one like we have ever had reported (and it has been years), and I don’t see a clean way to fix it, and there’s an easy workaround available. So let’s just take the workaround for now.

... will be always false iff the three constants are equal. And that's the very point of the test.

Yes - that's why I started the paragraph with "all three names are constants" :)

I don't think I've ever seen an init check to see if constants have been tampered with. Is that something that you expect your users to do? I think this is why this false positive has never been brought up before, like Josh says.

Is that something that you expect your users to do?

I'm the prime suspect any time in the future. Been there, done that ;-)

My previous comments weren't completely correct. The check documentation reads:

checkSuspect checks for expressions of the form
  x != c1 || x != c2
  x == c1 && x == c2
where c1 and c2 are constant expressions.
If c1 and c2 are the same then it's redundant;
if c1 and c2 are different then it's always true or always false.
Exprs must contain only side effect free expressions.

So this kind of expression is exactly what the vet check is supposed to flag. I mostly agree with Josh, that it should be easy enough for now to avoid this pattern and see if there are any other false positives reported in the future.

I was going to pull in the boolean check author for some second thoughts, but he's ahead of me :)

commit 7da5f193b77edcfcf26ac513864432001693735a
Author: Josh Bleecher Snyder <josharian@gmail.com>
Date:   Wed Jul 2 10:39:57 2014 -0700

    go.tools/cmd/vet: detect stupid boolean conditions

I still don't get where from comes the idea that there's anything wrong with the above quoted expressions.

Please ELI5 why, for example, a test for violating invariant a == b && a == c, written as if a != b || a != c { ... } should be rejected by vet, given a, b and c are constants, considering constants may change during code development/debugging etc.

If some/all of a, b, c would be constant values (literals), ie. not constant names, then the rejection would be obviously correct. (Like in a == 42 && a == 278)

I think it doesn't distinguish named constants from unnamed ones. Perhaps it should - that would cover this false positive, but it might introduce some false negatives. It looks like none of the current tests use user-defined constants, so that might work. nil should still trigger the check, of course.

@josharian thoughts?

I think it doesn't distinguish named constants from unnamed ones.

That's correct.

I think it'd be useful to gather some data from a corpus about the nature of the constant expressions when this check fires.

I think the ultimate solution is to make this a warning. Along with unused import/variables, short edits in code for debugging is painful in Go.

@dfang This is not related to the issue reported in this thread, assuming authType is a variable.

This:

authType != "scan" || authType != "web"

is equivalent to true for all possible values of authType, so vet is right: that condition is suspicious. It's not checking anything. It's always true.

Moreover, this:

!(authType == "scan" || authType == "web")

is not equivalent to

authType != "scan" || authType != "web"

so your change is not correct. For example, if authType is "scan" the first condition if false, but the second is true.

Falling in the last line is weird because I don't see why you would implement x == a == b but @cznic is right the column x!= a or x!=b is not always true.