jnr / jnr-constants Goto Github PK

// SOL_IP not defined
// SOL_TCP not defined
// SOL_UDP not defined

they're not defined on any platform, but they should be defined on Linux. I didn't find them manually in my header files, CRuby has to do some nasty tricks under the hood... ?

workaround for puma: puma/puma#2350

As far as I understand these are supported since kernel 2.6 or smth

O_NOINHERIT is the Windows equivalent of O_CLOEXEC. In order to start using O_NOINHERIT in JRuby, I need this constant added (and generated) for all backends (fake, xplatform, platform).

Should just be a matter of adding it and generating fake, xplatform, and at least Windows platform.

I'll get to it in the morning, perhaps.

OS:
15.6.0 Darwin Kernel Version 15.6.0: Thu Jun 23 18:25:34 PDT 2016; root:xnu-3248.60.10~1/RELEASE_X86_64 x86_64

jruby 9.1.3.0-SNAPSHOT (2.3.0) 2016-07-28 75b925c Java HotSpot(TM) 64-Bit Server VM 25.102-b14 on 1.8.0_102-b14 [darwin-x86_64]

pry(main)> s.getsockopt(Socket::SOL_SOCKET, Socket::SO_LINGER)
Errno::ENOPROTOOPT: Protocol not available - Protocol not available
from org/jruby/ext/socket/RubyBasicSocket.java:265:in `getsockopt'

pry(main)> Socket::SO_LINGER
=> 128
pry(main)> Socket::SOMAXCONN
=> 128

getsockopt method:

    public IRubyObject getsockopt(ThreadContext context, IRubyObject _level, IRubyObject _opt) {
        Ruby runtime = context.runtime;

        SocketLevel level = SocketUtils.levelFromArg(_level);
        SocketOption opt = SocketUtils.optionFromArg(_opt);

        try {
            Channel channel = getOpenChannel();

            switch(level) {

            case SOL_SOCKET:
            case SOL_IP:
            case SOL_TCP:
            case SOL_UDP:

                if (opt == SocketOption.__UNKNOWN_CONSTANT__) {
                    throw runtime.newErrnoENOPROTOOPTError();
                }

SocketOption.valueOf(128) returns __UNKNOWN_CONSTANT__.

On MRI 2.3.1:

[1] pry(main)> require 'socket'; s = Socket.tcp('localhost', 6379); s.getsockopt(Socket::SOL_SOCKET, Socket::SO_LINGER)
=> #<Socket::Option: INET SOCKET LINGER off 0sec>
[2] pry(main)> Socket::SO_LINGER
=> 128
[3] pry(main)> Socket::SOMAXCONN
=> 128

The AIX platform is missing constants. This causes the fake platform to get pulled in, which causes bad behavior and eventual crashes.

The fake platform doesn't seem like a very good idea; most people would rather have a program fail loudly and clearly on missing constants than have their programs silently do the wrong thing
before failing for obscure and difficult-to-diagnose reasons. It would probably be better to simply fail on an error if a platform can't be found than default to a possibly-incorrect set of values that may work in some cases and may fail when an incorrect value is depended upon. This ends up making debugging very difficult, because the site of the crash is often very far-removed from the actual site of error, and the bugs thrown are often quite obscure (things like files being opened with slightly wrong modes that allow it to work in some cases but not others.

Either way, I've got a pull request incoming to add the AIX constants.

I have already reported this issue in the original repo with no luck, so let me repeat it here.

Trying to embed jruby within an app in a jar fails due to java.lang.NullPointerException at com.kenai.constantine.Platform.getPackageName(Platform.java:39). Seems like com.kenai.constantine.Platform.getPackageName returns nil under these circumstances. As a quick fix, changing the implementation to return hardcoded "com.kenai.constantine" resolves this issue. I lack Java knowledge to debug this issue in more detail and find the root cause.

For detailed report, see:
http://www.ruby-forum.com/topic/211334

Here is the code (of Moneydance extension) that I try to embed jruby-complete into:
http://github.com/arvicco/moneydance-ruby

JNR Constants 0.8.6 - Dual licensed ASL/LGPL. Five files are MIT Only licensed.

code/jnr-constants-jnr-constants-0.8.6/src/main/java/com/kenai/constantine/Constant.java
code/jnr-constants-jnr-constants-0.8.6/src/main/java/com/kenai/constantine/ConstantSet.java
code/jnr-constants-jnr-constants-0.8.6/src/main/java/com/kenai/constantine/platform/ConstantResolver.java
code/jnr-constants-jnr-constants-0.8.6/src/main/java/jnr/constants/Constant.java
code/jnr-constants-jnr-constants-0.8.6/src/main/java/jnr/constants/ConstantSet.java
code/jnr-constants-jnr-constants-0.8.6/src/main/java/jnr/constants/Platform.java
code/jnr-constants-jnr-constants-0.8.6/src/main/java/jnr/constants/platform/ConstantResolver.java

Is this expected? Does it change from system to system?

Also, if one ask for the value it returns a completely wrong value, which is fairly unpractical.
65536 in my case, instead of the right value 256.

I think undefined values should return 0, that would be less surprising.

moving the discussion from jruby/jruby#6843

we have a set of constants based on the platform we know
https://github.com/jnr/jnr-constants/blob/master/src/main/java/jnr/constants/platform/linux/AddressFamily.java
and some of them aren't defined

if we load them like this
https://github.com/jruby/jruby/blob/8f25a744ef7f24bbda63cdf00f72784192102d76/core/src/main/java/org/jruby/Ruby.java#L4597

require 'socket'
Socket.constants =>[AF_UNSPEC, AF_LOCAL, ....]

but for instance AF_IMPLINK won't be in the list on Linux

this is useful for feature checks like the one in Puma
https://github.com/puma/puma/blob/20dc923b0b83a829cc3e2578a2b2c0b854985c18/lib/puma/server.rb#L124

however, if there's a platform that isn't supported, we do load "fake constants"
https://github.com/jnr/jnr-constants/blob/master/src/main/java/jnr/constants/platform/fake/AddressFamily.java

in this case, suddenly Socket.constants will include all possible constants, so
Socket.const_defined?(:IPPROTO_TCP) will return true and the code that expects the feature to be supported breaks.

we're saying that we do support everything, but it's a false assumption.

I think it would be nice to be able to detect if these constants are real or not.
Note that fake constants aren't close to any platform and any code that depends on correct values for doing native calls will almost for sure break (mostly on unexpected and hard-to-track errors).
Of course, I can do a second platform check in JRuby to achieve the same goal, but it would be cleaner if jnr-constants could handle platform differences and give me the information about usability instead of trying to fake it.

this is just a topic for discussion based on the previous task I was working on. I have a workaround so feel free to close it :)

Could you add support for graalvm native-image to support JNA's constant resolution?

The asinine thing is that ConstantSet:143 swallows the ClassNotFoundException exception so that I can't figure out what classes to whitelist for reflection.

Why not code the constants manually by using preprocessed files like this for termios.h on Linux:
echo "#include <termios.h>" > c.c
gcc -dD -dI -E c.c > _termios-prepocessed.h
Doing this once will give you all defines,structures, function calls in _termios-prepocessed.h, so you can later check or add something even if you have no access to the said hardware?

I have no idea how the copyright is affected if the preprocessed files are stored in the source repository.

And maybe go away from enums to abstract classes that hold the defined values in final public (long|int|short|String) fields?

It seems we lost more enums than I realized.

This bug tracks work to get the enums all repaired so that downstream projects are not broken with newer jnr-constants.

POSIX.1.2008 added quite a few for constants including FD_CLOEXEC.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html

We now have O_CLOEXEC as a constant. We need FD_CLOEXEC for the fcntl version of it.

Windows defines O_NOINHERIT instead of O_CLOEXEC. If it has a similar equivalent to FD_CLOEXEC we should define that as well.

I think these just go in Fcntl since they're defined there (at least on MacOS).

Is there a reason that O_DIRECT couldn't be added to OpenFlags? Would you accept a PR for it?

For my specific use case, I'm getting some Java code ready to run on both x86-64 and aarch64, and it's inconvenient that the (currently hard-coded constant) for O_DIRECT on x86-64 maps to the value of O_DIRECTORY on aarch64.

This is used by C Ruby in a few places, but we do not define it. It does not appear to be a standard SO constant, but we probably should have it anyway.

The values for several constants appear to differ on PPC Linux versus other architectures, and in #67 we hope to implement support for per-arch constants. Once this is in place, we will want to at least regenerate constants on PPC, since there are several there that caused errors in jnr/jnr-posix#144 and may be causing problems for other users on non-x86 Linux platforms.

We will also want to explore other OS + architecture combinations and ensure we have proper constants for them.

Note that some of this logic appears to have been implemented; ConstantSet has code in place that looks for platform-specific constants in both the platform.<os> and platform.<os>.<arch>, but apparently the process of generating the arch-specific constants never was written.

In jnr/jnr-posix#144 we discovered that several socket options have different values on PPC Linux versus other platforms (presumably x86). Specifically, the SO_PASSCRED option for receiving sender's credentials (uid, pid, and gid) with recvmsg does not match. The related test in jnr-posix failed because the credentials were not delivered.

In order to support this, we need a way to generate and load constants that may differ across CPU architecture, not just across OS. This bug is a placeholder until we can do that work.

I hava problem with logstash running in mips64el, The performance is that logstash cannot automatically create an index file. Later I found out that it was a problem with this project. jnr calls the function open(filename,flags,perm) of the c library, but the openflags value of different archtiectures are different. You can refer to the definition of the musl c library.

x86 https://git.musl-libc.org/cgit/musl/tree/arch/generic/bits/fcntl.h
arm https://git.musl-libc.org/cgit/musl/tree/arch/arm/bits/fcntl.h
mips64 https://git.musl-libc.org/cgit/musl/tree/arch/mips64/bits/fcntl.h

Currently, the code generated by this project localte at platform/linux, does not differentiate cpu architecture. Maybe platform/linux/amd64 and platform/linux/mips64 more suitable.

Althouth I solved the problem by local replacement, i think it is not the perfect solution. So I would like to ask you opinion on this issue.

Attach my locally generated code.

diff --git a/src/main/java/jnr/constants/platform/linux/OpenFlags.java b/src/main/java/jnr/constants/platform/linux/OpenFlags.java
index 47dd622..8416823 100644
--- a/src/main/java/jnr/constants/platform/linux/OpenFlags.java
+++ b/src/main/java/jnr/constants/platform/linux/OpenFlags.java
@@ -1,27 +1,27 @@
 // WARNING: This file is autogenerated. DO NOT EDIT!
-// Generated 2018-09-20 16:28:34 +0000
+// Generated 2021-06-01 09:57:03 +0000
 package jnr.constants.platform.linux;
 public enum OpenFlags implements jnr.constants.Constant {
 O_RDONLY(0L),
 O_WRONLY(1L),
 O_RDWR(2L),
 O_ACCMODE(3L),
-O_NONBLOCK(2048L),
-O_APPEND(1024L),
-O_SYNC(1052672L),
+O_NONBLOCK(128L),
+O_APPEND(8L),
+O_SYNC(16400L),
 // O_SHLOCK not defined
 // O_EXLOCK not defined
-O_ASYNC(8192L),
-O_FSYNC(1052672L),
+O_ASYNC(4096L),
+O_FSYNC(16400L),
 O_NOFOLLOW(131072L),
-O_CREAT(64L),
+O_CREAT(256L),
 O_TRUNC(512L),
-O_EXCL(128L),
+O_EXCL(1024L),
 // O_EVTONLY not defined
 O_DIRECTORY(65536L),
 // O_SYMLINK not defined
 // O_BINARY not defined
-O_NOCTTY(256L),
+O_NOCTTY(2048L),
 O_TMPFILE(4259840L),
 O_CLOEXEC(524288L);
 private final long value;

From OS X flock(2), for example:

ERRORS
     The flock() call fails if:

     [EWOULDBLOCK]      The file is locked and the LOCK_NB option was specified.

     [EBADF]            The argument fd is an invalid descriptor.

     [EINVAL]           The argument fd refers to an object other than a file.

     [ENOTSUP]          The referenced descriptor is not of the correct type.

Originally reported here. We use fake and fake returns some bogus values for windows so we should figure out how to generate AddressFamily:

jruby/jruby#1509

It's available in more recent kernels. Do you have a way to handle kernel versioning, or is it safe to just add it?

The definition in this IoctlFlags.rb wont be generated - The output file is empty.

1. Under this error condition there should be no output file at all.
2. Where is the bug? (I dont know who is responsable fot his ;-).
   IoctlFlags.rb.txt

Arne

Sorry to add this as an issue but I couldn't see where else to raise it.

Ref: jnr-constants-0.9.0.jar

We are conducting export control checks on software that uses this library and have identified it as potentially containing cryptography.

As the download links for this library are hosted by github can the developers please confirm whether the required notification under the EAR related to open source encryption source code has been made to US Government or advise the grounds why the developers deem such notification isn’t required?

The requirement comes from US EAR legislation and github T&Cs relating to submissions.

"You may not use GitHub in violation of export control or sanctions laws of the United States or any other applicable jurisdiction. You may not use GitHub if you are or are working on behalf of a Specially Designated National (SDN) or a person subject to similar blocking or denied party prohibitions administered by a U.S. government agency. GitHub may allow persons in certain sanctioned countries or territories to access certain GitHub services pursuant to U.S. government authorizations. For more information, please see our Export Controls policy."

https://help.github.com/en/github/site-policy/github-terms-of-service
https://help.github.com/en/github/site-policy/github-and-trade-controls

For background information and some FAQ’s please see
http://www.apache.org/dev/crypto.html
https://www.ecfr.gov/cgi-bin/text-idx?SID=00a8f54989eaf101a84eff3db59ac6e9&mc=true&node=se15.2.742_115&rgn=div88

Many thanks,
Rowland