Comment 1:

issue #835 maybe

Comment 2:

I think this issue can be closed as a duplicate of issue #835. Dpezely, can you show an
example where the value of EPOLLET is causing a problem for Go programs?

Status changed to WaitingForReply.

Comment 3 by dpsplunk:

Sufficient example appears in issue #835.  
However, explanation from rsc there doesn't resolve the fact that the value is still
incorrect today in this case.  
Ordinarily, I agree that values for some masks are better defined as explained there,
but there are exceptions.  This appears to be such an exception since the source
material from C already has a specific value.  
It would be different if the value originated with Go, but it doesn't in this case.

Comment 4:

I don't think I'm qualified to make a call on this, what exists now appears to be a
compromise that works well. I think the best solution may be for you to propose a
change, and hopefully the most knowledgeable folks like Iant will be able to make a
decision.
The details on contributing to the project are here,
http://tip.golang.org/doc/contribute.html

Labels changed: added priority-later, removed priority-triage.

Status changed to HelpWanted.

Comment 5:

EPOLLET is defined in the generated files zerrors_linux_{amd64,arm,386}.go.  Those files
are generated by the mkerrors.sh script in the pkg/syscall directory.  When I run
mkerrors.sh on my Ubuntu Precise amd64 system, I see EPOLLET defined as 0x80000000, not
-0x80000000.  This is only for 386 and amd64, not arm.
I see a few other additions, which are harmless.  In zerrors_linux_386.go, I see changes
to the values of F_GETLK, F_SETLK, and F_SETLKW; that looks like a bug.
Anyhow, I think this problem may simply be fixed.  At least if you rebuild the files on
a 64-bit host.  It would be interesting to see what zerrors_linux_arm.go looks like
after running mkerrors.sh on an ARM system.

Comment 6:

I don't believe we can change existing constants, but we can add new ones that people
should use instead.

Comment 7:

Labels changed: added go1.3maybe.

Comment 8:

Labels changed: added release-none, removed go1.3maybe.

Comment 9:

Labels changed: added repo-main.

Comment 10:

Issue #7217 has been merged into this issue.

It's correct in https://godoc.org/golang.org/x/sys/unix