Custom Query (245 matches)

Hi/2.

It is well known that some dlls alter FPU CW but do not restore it. So if those dlls are imported, FPU CW is altered at startup. This may cause SIGFPE later. To prevent this, it's good to initialize FPU CW at startup.

Hi/2.

A prototype of putenv() of kLIBC is:

int putenv(const char *);

But POSIX says at ​https://pubs.opengroup.org/onlinepubs/9699919799/functions/putenv.html:

int putenv(char *);

It would be better to conform to POSIX. In addition, FreeBSD doesn't use const, too. See ​https://www.freebsd.org/cgi/man.cgi?query=putenv.

The behavior of realpath() and stat() for paths containing path rewrite components is inconsistent.

In particular, realpath() behaves as if such components were symlinks. However stat() doesn't recognize them as symlinks and will not report the S_IFLINK mode bit for them.

For example, calling reaplath("/@unixroot/usr") will give you C:/usr (if UNIXROOT is set to C:). Given this, one might expect that "/@unixroot" is a symlink but apparentlystat("/@unixroot")shows that this is a false assumption.

This is not only a theoretical question. There is at least one program that is broken because of that: Python (at least the version hosted ​here and distributed in our RPM that supports symlinks and therefore makes a difference between abspath and realpath).

Its os.path.realpath function is implemented not as a call to the libc realpath() function (as one might expect) but as a loop that walks over individual path components and calls readlink on those of them for which islink returns true. However islink (eventually backed up by stat()) returns false for paths like /@unixroot. First of all, it will return false because stat() itself will fail (see #283) but even if we imagine that that failure is fixed and stat() starts to work, it will simply return 0 in the S_IFLINK so that islink will still return false.

Such a behavior of islink completely breaks os.path.realpath functionality for paths containing /@unixroot and similar. in such cases realpath will just return the same value as os.path.abspath.

I discovered this problem when I was trying to fix the Python's ​virtualenv script (used to create directory-local python environments on the fly). Virtualenv does some path rebasing which fails on OS/2 for Python installed from RPM because it can't detect that C:/usr and /@unixroot/usr is the same thing. In virtualenv they originally do path comparison after calling os.path.abspath. Replacing that with os.path.realpath would let us fix the problem but we can't do that since realpath itself doesn't work.