The spec gives well defined overflow behaviour, it roll over following two's complement modulus arithmetic.
It does not panic.

4294967295+21 = 20 is correct because there is an implicit modulus 2 power 32 (or 64 on 64bits arch) on all 32 bits operations.

The spec also allows ints and uints to vary in size.

This code does exactly what it is supposed to do. You should use uint64, safe math or big math librairies.

This has nothing to do with gob, unsigned ints are defined to wrap when they overflow.

closing as there is no bug

The spec gives well defined overflow behavior, it roll over following two's complement modulus arithmetic. It does not panic.

@seankhliao @Jorropo
I agree.
But client doesn't know which GOARCH used on server. With heavy math calculations client WILL TRUST any responses from server.
encoding/gob as default binary transporter between client-server MUST check architecture client/server before request/response.

@AlekseiLevykh it isn't a secure remote execution context.

The remote server can answer with whatever it wants anyway.

encoding/gob as default binary transporter between client-server MUST check architecture client/server before request/response.

I disagree, you should use uint when you don't care about it's size.

Here it seems you care about the size, just use uint64 then.

I would agree that a linter warning about using uint or int in gobiable structs would be nice, (I mean a third party one, not gofmt nor govet), but I don't think this is worth checking at runtime.