make generic "Out of memory!" error more specific The problem: When perl runs out of memory, it outputs a generic "Out of memory!" error and exits. This makes it hard to track down what's happening in a complex system, especially since the message does not even mention perl. This patch contains two main changes: 1. vec() in lvalue context can throw fake "Out of memory!" errors when it discovers that the index being assigned to is too big. Unlike real allocation errors, these are trappable with try {}/eval {}. This message has been changed to "Out of memory during vec in lvalue context" (and since it comes from a Perl_croak() call, it will generally have a script name and line number attached). 2. All other places in the source code that can emit "Out of memory!" errors have been changed to attach a location identifier to the message. For example: "Out of memory in perl:util:safesysmalloc" This way the error message at least mentions "perl". Fixes #21672.
win32: default the shell to cmd.exe in the Windows system directory This prevents picking up cmd.exe from the current directory, or even from the PATH. This protects against a privilege escalation attack where an attacker in a separate session creates a cmd.exe in a directory where the target account happens to have its current directory.
win32: inject a socket-aware version of CloseHandle() into the CRT _close() on an fd calls CloseHandle(), which is illegal if the fd contains a socket handle. We previously worked around this by having our own close(), which called closesocket() before calling _close() (e601c439adce167078ac7b49550c0418ace86f94). Amusingly, the author of that solution thought it's just a temporary workaround: /* * close RTL fd while respecting sockets * added as temporary measure until PerlIO has real * Win32 native layer * -- BKS, 11-11-2000 */ To make it thread-safe, we had to manipulate the internals of file descriptors, which kept changing (b47a847f6284f6f98ad7509cf77a4aeb802d8fce). Unfortunately, the C runtime has been rewritten and it no longer exposes them at all. We had to disable the thread-safety fix in Visual C++ 2015 builds (1f664ef5314fb6e438137c44c95cf5ecdbdb5e9b). It also wouldn't work with MinGW configured to use UCRT. This commit introduces a new solution: we inject a socket-aware version of CloseHandle() into the C runtime library. Hopefully, this will be less fragile. This also fixes a few issues that the original solution didn't: - Closing a busy pipe doesn't cause a deadlock (fixes #19963) - _dup2 properly closes an overwritten socket (fixes #20920)
on win32 translate / to \ in symlink targets Windows, or at least NTFS, doesn't appear to follow symlinks where the target contains the POSIX directory separator "/". To fix that translate any / to \ in symlink targets. This may break code that checks the symlink target macthes a value set, but I think it's more likely to fix code that blindly uses / than break code that looks at the symlink target they just set. Fixes #20506
Correct typos as per GH 20435 In GH 20435 many typos in our C code were corrected. However, this pull request was not applied to blead and developed merge conflicts. I extracted diffs for the individual modified files and applied them with 'git apply', excepting four files where patch conflicts were reported. Those files were: handy.h locale.c regcomp.c toke.c We can handle these in a subsequent commit. Also, had to run these two programs to keep 'make test_porting' happy: $ ./perl -Ilib regen/uconfig_h.pl $ ./perl -Ilib regen/regcomp.pl regnodes.h
make win32_readlink() return PrintName instead of SubstituteName While debugging socket stat()ing I noticed that sometimes the name returned by win32_readlink() was a full pathname rather than the name that the link was created as. Changing this to use the PrintName values changed win32_readlink() to return the create as name, which seems closer to the POSIX readlink.
Win32 stat() didn't handle AF_UNIX socket files Unfortunately both symbolic links and sockets can only be "statted" by opening with FILE_FLAG_OPEN_REPARSE_POINT which obviously doesn't follow symbolic links. So to find if a chain of symbolic links points to a socket, is a broken chain, or loops, we need to follow the chain ourselves.