proposal: os: Chown expects int, but Linux uid_t/gid_t are uint32

[gopherbot]

Hi. I don't necessarily expect anything to change, but I wanted to record my
confusion/surprise in a place where others are likely to find it.

chown(2) takes takes uid_t and gid_t, which on Linux are unsigned 32-bit:
http://serverfault.com/questions/105260/how-big-in-bits-is-a-unix-uid

I have some code that deals with low-level kernel interfaces, where uids and gids are
most definitely uint32, and making those interact with os.Chown is what triggered this
issue.

Go will be confusing to use with userids 2147483648..4294967294. If you think nobody
will have that many users, consider containers and user namespaces; uids will not be
consumed in-order, like on traditional UNIX boxes.

And on 64-bit platforms, int is 64-bit, but uid values are only 32-bit, and that gets
silly too.

Background: In C, -1, when cast into uid_t (that is, uint32_t), is just 0xffffffff, the
highest possible unsigned value; it's not really signed, but just a shorthand for
"all bits set". In Go, trying to pass -1 as uint32 is a compiler error. This
sounds like the motivation for making the argument an int.

[ianlancetaylor]

Comment 1:

It looks like we made an unfortunate choice here, but the Go 1 compatibility guarantee
prevents us from changing it.  As far as I can see the current code will work, albeit
awkwardly, so it's not essential to do anything today.  Marking as a Go 2 issue.

Labels changed: added repo-main, go2.

Status changed to LongTerm.

[griesemer]

Comment 2:

Labels changed: added release-none.

[rsc]

cf #6495

[ianlancetaylor]

Let's fold this into the more general #6495.