Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

syscall: constant EPOLLET inconsistent with /usr/include/sys/epoll.h on Linux #5328

Closed
gopherbot opened this issue Apr 22, 2013 · 11 comments
Closed

Comments

@gopherbot
Copy link

@gopherbot gopherbot commented Apr 22, 2013

by dpsplunk:

See http://tip.golang.org/pkg/syscall/ and search in page for EPOLLET

Compare value against /usr/include/sys/epoll.h on Linux (or possibly
/usr/include/x86_64-linux-gnu/sys/epoll.h if on Ubuntu 12.04)

Go version has a negative value; whereas, Linux version is positive.

Value is positive on Linux Ubuntu 10.04 LTS and Ubuntu 12.04 LTS.
@alberts
Copy link
Contributor

@alberts alberts commented Apr 22, 2013

Comment 1:

issue #835 maybe
@davecheney
Copy link
Contributor

@davecheney davecheney commented Apr 25, 2013

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.

@gopherbot
Copy link
Author

@gopherbot gopherbot commented Apr 25, 2013

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.
@davecheney
Copy link
Contributor

@davecheney davecheney commented Apr 25, 2013

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.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 26, 2013

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.
@rsc
Copy link
Contributor

@rsc rsc commented Jul 30, 2013

Comment 6:

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

@rsc rsc commented Nov 27, 2013

Comment 7:

Labels changed: added go1.3maybe.

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 8:

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

@rsc
Copy link
Contributor

@rsc rsc commented Dec 4, 2013

Comment 9:

Labels changed: added repo-main.

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jan 27, 2014

Comment 10:

Issue #7217 has been merged into this issue.

@bradfitz
Copy link
Contributor

@bradfitz bradfitz commented Feb 2, 2017

@bradfitz bradfitz closed this Feb 2, 2017
@golang golang locked and limited conversation to collaborators Feb 2, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.