cgo: use true instead of 0 == 0 in the generated code

[ainar-g]

Inspired by dominikh/go-tools#430.

CL 142883 made it so that the code generated by cgo contains an always–true conditional 0 == 0 instead of the predefined identifier true. According to the comment, it is made to account for the case when true is redefined. I don't think that it was reasonable. Firstly, it still doesn't account for all cases of “stupid shadowing”, for example I can still define

_cgoCheckPointer := 0

in my code and break cgo. Secondly, do we really need to account for that? Wouldn't a message like “identifier foo must not be shadowed in cgo code” do the job?

[ainar-g]

An interesting way to combat shadowing would be a synthetic package:

package builtinbackup

const (
	True  = true
	False = false
)

func CGoCheckPointer( /* … */ ) { /* … */ }

It could then be used in the generated code like this:

builtinbackup.CGoCheckPointer(builtinbackup.CGoBase0, builtinbackup.True)

[bradfitz]

Why go through all that work either with a new package or a new warning message when 0 == 0 does the trick?

[ianlancetaylor]

I can't see any reason to change working code to make it work less well.

There is no reason to run a static checker on cgo output.

If I could change cgo to avoid names like _cgoCheckPointer, I would. But I don't see a way to do that. And it seems more reasonable for cgo to reserve names that start with _cgo than for it to reserve the name true.

[dominikh]

There is no reason to run a static checker on cgo output.

That isn't quite correct. We definitely want to check code that uses cgo, and we can't check cgo input since it isn't valid Go. So we do have to check the output.

It is, however, much simpler to add a special case to the check than to change how cgo generation works.