Should gosec rule G115 be on the default-exclusions list?

[FairlySadPanda]

Gosec rule G115 has recently caused me and others headaches. For context, this is a rule that covers potentially unsafe-casting of things like uint64s -> int64s.

I'm not that well-versed in the discussion about best practice on integer types in Go - it's an early language topic that is probably discussed somewhere in The Go Programming Language which I don't have to hand - but my understanding is that the language is designed assuming most developers will use int for everything. The problem is that this hasn't worked out like that; sometimes an API expects 32 bit numbers, for example.

This means that leaving G115 enabled tends towards a large amount of false-flags in otherwise-correct code. G115 doesn't have the ability to assess wider context, so even by sticking in handling code to cope with wraparound errors - even if that handling crashes the program or otherwise short-circuits - the cast is still flagged and needs to be manually ignored with a nolint comment.

I'm curious what folks think here. I was trained to view explicit casting as an "I know what I am doing here, type engine" override, a conscious decision to be responsible.

This rule ergo ends up feeling like it's only useful to actually run rarely, as part of an audit on casting to make sure assumptions have not drifted, rather than as part of a repeatable CI toolchain.

[ldez]

#4941