This partially reverts commit "Windows: Improve readablity of
getenv() encoding" 14453a256d.
The `getenv` macro defined here is to also substitute the function
in dln_find.c, not only in this file.
Now we require C99, these features available of course.
* prototypes
* stdarg prototypes
* token pasting
* stringization
* string literal concatenation
* Windows: Read ENV names and values as UTF-8 encoded Strings
Implements issue #12650: fix https://bugs.ruby-lang.org/issues/12650
This also removes the special encoding for ENV['PATH'] and some
complexity in the code that is unnecessary now.
* Windows: Improve readablity of getenv() encoding
getenv() did use the expected codepage as an implicit parameter of the macro.
This is mis-leading since include/ruby/win32.h has a different definition.
Using the "cp" variable explicit (like the other function calls) makes it
more readable and consistent.
* Windows: Change external C-API macros getenv() and execv() to use UTF-8
They used to process and return strings with locale encoding,
but since all ruby-internal spawn and environment functions use UTF-8,
it makes sense to change the C-API equally.
This partially reverts commit "Windows: Improve readablity of
getenv() encoding" 14453a256d.
The `getenv` macro defined here is to also substitute the function
in dln_find.c, not only in this file.
getenv() did use the expected codepage as an implicit parameter of the macro.
This is mis-leading since include/ruby/win32.h has a different definition.
Using the "cp" variable explicit (like the other function calls) makes it
more readable and consistent.
On mingw, wmemcpy() is defined as an inline function using
memcpy(), and the static inline wrapper causes a warning.
```
In file included from include/ruby/ruby.h:39,
from win32/file.c:5:
include/ruby/internal/memory.h:284:16: warning: 'ruby_nonempty_memcpy' is static but used in inline function 'wmemcpy' which is not static
284 | #define memcpy ruby_nonempty_memcpy
| ^~~~~~~~~~~~~~~~~~~~
```
Recent (since 2012 maybe?) MSVC ships a header named xkeycheck.h, which
(kindly!) aborts compilation on redefinition of C++ keywords. Let's not
define this in case of C++.
C++ keyword `nullptr` represents a null pointer (note also that NULL is
an integer in C++ due to its design flaw). Its type is `std::nullptr_t`,
defined in <cstddef> standard header. Why not support it when the
backend implementation can take a null pointer as an argument.
Saves comitters' daily life by avoid #include-ing everything from
internal.h to make each file do so instead. This would significantly
speed up incremental builds.
We take the following inclusion order in this changeset:
1. "ruby/config.h", where _GNU_SOURCE is defined (must be the very
first thing among everything).
2. RUBY_EXTCONF_H if any.
3. Standard C headers, sorted alphabetically.
4. Other system headers, maybe guarded by #ifdef
5. Everything else, sorted alphabetically.
Exceptions are those win32-related headers, which tend not be self-
containing (headers have inclusion order dependencies).
prelude.c is an automatically generated file by template/prelude.c.tmpl.
However it does not contain any required functions. So remove it from
dependency.
Also miniprelude.c is included by mini_builtin.c and does not need
to make miniprelude.o.
Warned at making precompiled header on mswin.
```
building rb_mjit_header-2.7.0.pch
vm.c
d:\a\ruby\ruby\src\vm_args.c(1117): warning C4047: '=': 'const rb_callable_method_entry_t *' differs in levels of indirection from 'int'
rb_mjit_header-2.7.0.pch updated
```
