ISO/IEC 9899:1999 section 6.5.7 states that "If the value of the right
operand is negative or is greater than or equal to the width of the
promoted left operand, the behavior is undefined". So we have to take
care of such situations.
This has not been a problem because contemporary C compilers are
extraordinary smart to compile the series of shifts into a single
ROTLQ/ROTRQ machine instruction. In contrast to what C says those
instructions have fully defined behaviour for all possible inputs.
Hence it has been quite difficult to observe the undefined-ness of such
situations. But undefined is undefined. We should not rely on such
target-specific assumptions.
We are fixing the situation by carefully avoiding shifts with out-of-
range values. At least GCC since 4.6.3 and Clang since 8.0 can issue
the exact same instructions like before the changeset.
Also in case of Intel processors, there supposedly be intrinsics named
_rotr/_rotl that do exactly what we need. They, in practice, are absent
on Clang before 9.x so we cannot blindly use. But we can at least save
MSVC.
See also:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57157https://bugs.llvm.org/show_bug.cgi?id=17332
MJIT with ccache has a problem on docker environment, so
we need to use original CC (/usr/bin/gcc, for example).
Ubuntu system provides /usr/lib/ccache/gcc and so on to use
gcc with ccache. It is easy to setup ccache by adding
/usr/lib/ccache to $PATH. However we need to use /usr/bin/gcc
(and so on) for MJIT_CC. We can specify MJIT_CC option at
configure, but specifying them is troublesome.
This patch choose original $CC (/usr/bin/gcc, for example)
if $CC is /usr/lib/ccache/$CC.
The use of RUBY_WERROR_FLAG causes this test to fail on OpenBSD
platforms that use the binutils linker (ld.bfd) instead of the
llvm linker (ld.lld), due to warnings added to the binutils linker
in OpenBSD.
Removing the RUBY_WERROR_FLAG would probably also fix it, but that
would affect other platforms.
This should also be backported to Ruby 2.7.
Analysis and similar fix recommended by George Koehler.
With these macros implemented we can write codes just like we can assume
the compiler being clang. MSC_VERSION_SINCE is defined to implement
those macros, but turned out to be handy for other places. The -fdeclspec
compiler flag is necessary for clang to properly handle __has_declspec().
On cross-compilation, compiled binary can no be created because
compiled binary should be created by same interpreter (on cross-
compilation, host ruby is used to build ruby (BASERUBY)).
So that cross-compilation system loads required scripts in text.
It is same as miniruby.
Downstream C++ projects that compile with C++11 or newer and include
the generated config.h file issue compiler warnings. Both C and C++
compilers do string-literal token pasting regardless of whitespace
between the tokens to paste. C++ compilers since C++11 require such
spaces, to avoid ambiguity with the new style of string literals
introduced then. This change fixes such projects without affecting
core Ruby.
icc_version was wrongly defined as "__ICC" on non-icc C compiler, which
caused a warning:
```
./configure: line 8211: test: __ICC: integer expression expected
```
This change adds a sed commend to delete "__ICC".
The icc_version guessing was accidentally disabled because of
61885c9b7ca8ccdaf53d7c365fbb86bad3294d88; `AC_PROG_CC_C99` changes
CC like "icc -std=c99", and `AS_CASE(["x$CC"], [xicc],` does not match.
The variable `icc_version` is eventually defined, so the `AS_CASE` is
not needed. This change removes the `AS_CASE`.
This approach is simpler than the previous approach which tries to
emulate realpath(3). It also performs much better on both Linux and
OpenBSD on the included benchmarks.
By using realpath(3), we can better integrate with system security
features such as OpenBSD's unveil(2) system call.
This does not use realpath(3) on Windows even if it exists, as the
approach for checking for absolute paths does not work for drive
letters. This can be fixed without too much difficultly, though until
Windows defines realpath(3), there is no need to do so.
For File.realdirpath, where the last element of the path is not
required to exist, fallback to the previous approach, as realpath(3)
on most operating systems requires the whole path be valid (per POSIX),
and the operating systems where this isn't true either plan to conform
to POSIX or may change to conform to POSIX in the future.
glibc realpath(3) does not handle /path/to/file.rb/../other_file.rb
paths, returning ENOTDIR in that case. Fallback to the previous code
if realpath(3) returns ENOTDIR.
glibc doesn't like realpath(3) usage for paths like /dev/fd/5,
returning ENOENT even though the path may appear to exist in the
filesystem. If ENOENT is returned and the path exists, then fall
back to the default approach.
卜部昌平
Koichi Sasada
Jeremy Evans
Matt Valentine-House
Nobuyoshi Nakada
Mark Abraham
Kazuhiro NISHIYAMA
Yusuke Endoh
David CARLIER
Samuel Williams
Lars Kanis