Failed double test on OpenBSD

[jturner]

I decided to take a look at Fexl again after...well it looks like 2 years based on my old issues. With my current pull request and 2 other OpenBSD specific tweaks (remove -ldl and nomove RTLD_NODELETE since OpenBSD doesn't need the former and doesn't support the latter) Fexl built and runs just fine on my amd64 OpenBSD -current system. One thing when I run .check a1 it seems the try (/ 0.0 0.0) test returns nan instead of -nan on my system any ideas?

Thanks.

[chkoreff]

I'm thinking the (/ 0.0 0.0) case is a serious gray area, very machine-specific. I wrote a little C program ("nan.c"):

#include <stdio.h>
int main(void)
  {
  double x = 0.0/0.0;
  printf("%.15g\n", x);
  }

Then "cc nan.c; ./a.out", with the result:

-nan

However, if I insert this line:

  x = x > 0 ? x : -x;

Then as expected the result is just "nan". Weird floating point stuff. (Actually x < 0 works too, because all comparisons with nan always fail.)

Regarding "-ldl" and "RLTD_NODELETE", I'm gonna focus on making it more portable. Again, I don't have an OpenBSD environment yet, but I get I can call uname from the build script and compare it with "OpenBSD", and conditionally exclude the "-ldl".

For RLTD_NODELETE, I'll need to research the appropriate C preprocessor flag. Any ideas on that one?

When I get an allegedly portable version done, you can test a build with no modifications.

Thanks for your interest!

[chkoreff]

I just pushed a change:

1. Do not use RTLD_NODELETE.
2. Make the (/ 0.0 0.0) test say "nan" always, instead of "-nan" on some machines.

In the next round, I'll eliminate -ldl in the build script when running on OpenBSD.

[chkoreff]

OK, I now think that you have a version of Fexl which will build on OpenBSD right out of the box. The ".check a1" test should also pass perfectly.

Let me know if that's true for you, and I will officially bless the result by closing this issue.

Thanks, Patrick

[jturner]

Yup I can confirm everything builds right out of the box on OpenBSD. The only test that still technically fails is the test_readlink since OpenBSD doesn't have a /proc filesystem otherwise .check a1 passes. Thanks.

[chkoreff]

Yikes, I wonder how I'm going to get the equivalent of "/proc/self/exe" on OpenBSD. There must be some way, because I'm sure OpenBSD supports "$0" in the shell, and that's essentially the same thing.

This is going to be important to me because I want to write completely location-independent Fexl scripts, which can exist in any directory, and which you can run from any directory.

Hmm. Any ideas on how OpenBSD implements $0?

[chkoreff]

Check this out:

http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

Free BSD:            readlink /proc/curproc/file
NetBSD:               readlink /proc/curproc/exe
DragonFly BSD:  readlink /proc/curproc/file

Could you try those for me on BSD? Like this:

say (readlink "/proc/curproc/file")
say (readlink "/proc/curproc/exe")

Thanks.

[jturner]

Nothing, my understanding is OpenBSD does not support the procfs and FreeBSD does, but not by default.

sysctl(3) is the normal way to return this type of information, but again in OpenBSD you can not get the path of an executable from sysctl. As far as I know, there is no way to determine the full path of the current executable from it's self in OpenBSD.

Chromium has this same problem their work around is as follows

#elif defined(OS_OPENBSD)
      // There is currently no way to get the executable path on OpenBSD
      char* cpath;
      if ((cpath = getenv("CHROME_EXE_PATH")) != NULL)
        *result = FilePath(cpath);
      else
        *result = FilePath("/usr/local/chrome/chrome");
      return true;
#endif

[chkoreff]

Hmm, I wonder who's setting that CHROME_EXE_PATH variable.

There's also this:

http://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

Excerpt:

Some shells, including bash and ksh, set the environment variable "_" to the full path of the executable
before it is executed. In that case you can use getenv("_") to get it. However this is unreliable because
not all shells do this, and it could be set to anything or be left over from a parent process which did not
change it before executing your program."

The whole subject doesn't sound too promising.