Proposal: flag: add support for int32 and uint32 options

[rvegas]

Currently many core libraries like grpc have configurable flags and options that are either int32 or uint32, e.g.

• HTTP2 Server Max Concurrent Streams
• Internal Poll Socket Opt in Windows

This forces the userland code for any configurable system to look something like this:

...
maxConcurrentStreams := f.Int("max_streams", 100, "Number of maximum concurrent streams")
f.Parse()
...
maxConcurrentConnectionsOption := grpc.MaxConcurrentStreams(uint32(maxConcurrentStreams))
...

Such casting (and any other workaround) results in error prone implementations sometimes, since the error handling has to be done by the developer, which I'm not particulary against, but it's better if we could trust Go's core flag parsing library to support and validate this.

In this manner, we could allow the implementations to simply look like this:

maxConcurrentStreams := f.Uint32("max_streams", 100, "Number of maximum concurrent streams")
f.Parse()
...
maxConcurrentConnectionsOption := grpc.MaxConcurrentStreams(maxConcurrentStreams)
...

I know it may look simple but flag already supports int, int64 and float64, so imho, adding this makes sense and allows for better looking and more secure code.

[rvegas]

I've opened #26465 with the necessary implementation to add this to flag.

[mvdan]

I'm not sure that the presence of int64 and uint64 sets a precedent. I imagine they were added so that one can have numerical flags that accept very large values without having to worry about 32-bit builds.

[rvegas]

@mvdan the reason for adding uint32 and int32 is not due to the precedent of other types.

The main reason behinf all of this is to allow core libraries users to be able to produce homogeneous code that is less error prone in basic implementations.

I do agree with the thought of having added *64 types for build-related reasons tho.

[bcmills]

You can already use flag.Var to declare a flag variable with an arbitrary validation function (the Set method), and flags in general may require different validation constraints: for example, some must be nonzero, or must fit in a uint32 after adding 12 (to account for some prefix added by the package), etc.

So what's special about the uint32 and int32 constraints? (If you believe they're more common than other validators, some statistics or examples would help.)

[bcmills]

Re the boilerplate conversions being less secure, it seems like #19624 would address the same security concerns much more generally. If you have specific examples of security bugs caused by conversions missing range checks, please mention them there!

[rsc]

int/uint and int64/uint64 should be enough. We don't need the entire set. Note that if uint32 is a very important type (such as in this particular package) it's easy to build a uint32-accepting flag.Var, as @bcmills pointed out above.