Good news:
I have the new code, written, TESTED, and ready to commit.

Problem:
This touches multiple files, in small ways.
I made separate "git commit" calls locally, so that the details of the individual files would get commented.
Then tried to do a unified "git change".
But it wont let me do that.

git-codereview: cannot amend change: multiple changes pending:
fd3cb4e update type of fcntl to properly have 3rd arg as uintptr, to be fully standard compliant
b33df1f update type of fcntl to properly have 3rd arg as uintptr, to be fully standard compliant
8f2c662 New test based around flock_test.go, but using Fcntl directly, rather than FcntlFlock
2594872 Exported fcntl as Fcntl
4a0a565 Updated third arg to fcntl to match new definition (int -> uintptr)

So, how should I proceed?
It feels wrong to me to submit each of these file changes as a separate change, since if for example, only one were accepted, it would BREAK builds, until the rest were accepted.

I am trying to follow "Multiple-Commit Work Branches" paragraph in the git-codereview docs, but it seems to be missing a few steps.
I've even tried ensuring that the Change-Id value is the same on all commits.. but it still refuses to allow me to run "git-codereview change".

??

PS: just so I dont forget, I'm noting here that if my code changes are accepted, there will need to be a robo-auto-update, to fix the autogenerated zsyscall_xxx files (since I was informed that may only happen on the official build farm)

(Pasting from my reply in https://golang.org/cl/104255)

After reading https://golang.org/pkg/unsafe/#Pointer and checking on the discussion around the introduction of the Ioctl* functions (which are quite similar in the way they work), I think we shouldn't add a raw exported Fcntl at all. Regardless of whether arg is int or uintptr, users would have to use unsafe.Pointer if they want to pass pointers.

E.g. see the discussion in https://golang.org/cl/44009 and #12574, especially Ian's comments #12574 (comment) and #12574 (comment).

Thus, I'd propose to add Fcntl* functions for each specific type (we already have FcntlFlock anyway) which will use the currently existing fcntl function. We might want to change its implementation to use uintptr arg instead of int.

This would allow users to use these functions in a type-safe manner without using the unsafe package.

@bradfitz, @ianlancetaylor what do you think?

Agree. Specific type-safe fnctl sounds good.

Change https://golang.org/cl/104736 mentions this issue: x/sys/unix: add FcntlInt