z/OS has extra fields which give the character set associated with the
object. Previously, there were a bunch of functions called to deal with
these.
This all falls away if we #ifdef these fields when accessing the
structure.
These are the two outlier header files that didn't have their #inclusion
recursion guard name end in _H. It's a small thing, but having that
standard simplifies a pattern in changes I'm making to Devel::PPPort
Note, non-standard used of "static link" below, I am using it to refer
to static importing funtions/data symbols from another DLL, using the
PE import table. Opposite of "LoadLibrary()"/"GetProcAddress()"
linking. I am NOT using "static link" in typical usage of fully including
a copy of a library at compile time, through a .a/.lib/.o/.obj file.
Since commit
Revision: af2f850fb5b3bd37dab6742ca16cce6aa5482fb9 10/19/2015 5:47:16 PM
const vtables in win32/perlhost.h
the vtables have been stored in read-only memory. There have been no bug
tickets or complaints since, of any users, wanting or depending on this
runtime instrumentation system.
All Win32 perl builds, are static DLL linked to a specific MSVCRT (LIBC)
at interp C compile build time. No matter the name of the CRT DLL,
msvcrt.dll, msvcrt120.dll, ucrtbase.dll, etc. Runtime swapping the
libperl MSVCRT DLL by an embedder, to his favorite CRT DLL, has never
been supported, and wouldn't even work, since perlhost.h's hooking isn't
perfect, and often Win32 Perl uses "win32_*()" functions by accident, or
explictly, and those static-link call into the hard coded CRTs. Plus
prototypes of CRT posix-ish functions have changed over the years.
What is time_t? stat_t? etc. While func symbol name stays the same.
The original commit for all this complexity, was from 5.0/5.6 era, where
it was assumed, perl 5 maint/stable releases will be abandoned by P5P
in favor of Perl 6, and all this complexity were provisions and APIs,
to fix, upgrade and improve Win32 Perl, on Microsoft's/ActiveState's
rapid release schedule, without any dependency on
P5P devs/pumpking/P5P policy, about releasing a new perl5 .tar.gz.
0f4eea8fa1779e08575278392ed398ffeda6dcd2 6/19/1998 6:59:50 AM
commoit title "applied patch, along with many changes:"
"The features of this are:
1. All OS dependant code is in the Perl Host and not the Perl Core.
(At least this is the holy grail goal of this work)
2. The Perl Host (see perl.h for description) can provide a new and
improved interface to OS functionality if required.
3. Developers can easily hook into the OS calls for instrumentation
or diagnostic purposes."
None of these provisions and APIs, have ever been used. CPerlHost:: never
became a separate DLL. Perl >= 5.12 has a "rapid release" policy.
ActiveState dropped sponsorship/product interest in Win32 Perl, many years
ago. Strawberry Perl took over the market. CPerlHost:: is way too
over engineereed for perl's ithreads/psuedofork, which only requires
"1 OS process" and 2 %ENVs, and 2 CWDs, functionality. Most of the
CPerlHost::* methods are jump stubs to "win32_*();" anyways, and the
hooking is redundant runtime overhead, but that is for another commit.
This commit is about removing the pointless malloc() and memcpy() of the
plain C to C++ "thunk funcs" vtables, from the RO const master copy in
perl5**.dll to each "my_perl" instance at runtime.
On x64, copying the vtables to malloc memory, wasted the following amounts
of malloc() memory. These are the actual integers passed to malloc() by
CPerlHost::/perl. malloc() secret internal headers not included in these
numbers.
perlMem, 0x38
perlMemShared, 0x38
perlMemParse, 0x38
perlEnv, 0x70
perlStdIO, 0x138
perlLIO, 0xE0
perlDir, 0x58
perlSock, 0x160
perlProc, 0x108
The old design of malloc-ed vtables, seems to have been, from the
original devs not knowing, or a poor understanding, how MS COM
(C++ obj in plain C) and MSVC ISO C++ objects (almost same ABI), are
layed out in memory. The original devs realized, if they use a ptr to
global vtable struct, they can't "cast" from the child class like
VDir:: or VMem::, back to a CPerlHost:: obj which is a design
requirement here.
But they wanted to pass around child class ptrs like VMem::* instead of one
CPerlHost:: obj ptr, and those VMem:: ptrs must be seen in 'extern "C"'
land by plain C perl, since my_perl keeps 9 of these C++ obj *s as seperate
ptrs in the my_perl "plain C" struct. So instead they made malloced copies
of the vtables, and put those copies in the CPerlHost:: obj, so from a
child class ptrs, they can C++ cast to the base class CPerlHost:: obj if
needed.
This is just wrong. Almost universally, vtables are stored in const
RO memory. Monkey-patching at runtime is a Perl lang thing, and rare
to never in C/C++land.
The ptr to "plain C to C++ func thunk vtable", CAN NOT be stored
per VDir::* or per VMem::* ptr. You can't store them, per C++ tradition,
as the 1st member/field of a VDir::/VMem:: object.
The reason is, VDir::/VMem:: objects can have refcounts, and multiple
CPerlHost:: ptrs, hold refs to one VMem:: ptr. So there is no way to
reverse a random VMem:: ptr, back to a CPerlHost:: ptr.
Main examples are VMem:: "MemShared" and VMem:: "MemParse".
Also the C->C++ thunk funcs must pick/separate, between 3 VMem:: obj ptrs.
Which are "Mem", "MemShared" and "MemParse" and stored at different
offsets in CPerlHost::*, but all 3 VMem:: derived "classes",
must have the same plain-C vtable layout with 7 extern "C" func thunk ptrs.
B/c my minimal C++ knowledge and also not wanting to add even more C++
classes to iperlsys.h perlhost.h and perllib.c, and those new C++ classes
may or may not inline-away. Don't fix this with more C++ classes.
So fix all of this, by each CPerlHost:: obj storing a ptr to the RO
vtable instead of a huge RW inlined copy of the vtable.
To keep all previous design requirements, just use
"&cperlhost_obj->vmem_whatever_vtable" as the plain-C representation
of a VMem::* ptr, instead of
"&cperlhost_obj->IPerlWhateverMem.pMalloc".
The 1 extra pointer de-ref CPU machine op, in each perl core and perl xs
caller, that executes in "iperlsys.h" family of macros I think is
irrelavent compared to the savings of having RO vtables. It is the same
machine code length on x86/x64 in each caller, comparing old vs new.
This extra ptr deref to reach the vtable can be removed, and I will
probably do it in a future commit. Not done here for bisect/small patch
reasons.
"iperlsys.h" family of macros is for example, the macro
"PerlEnv_getenv(str);"
Specific example, for macro PerlMem_free() in Perl_safesysfree()
old before this commit
----
mov rax, [rax+0CE8h]
mov rcx, rax
call qword ptr [rax+10h]
-----
new after this commit
-----
mov rcx, [rax+0CE8h]
mov rax, [rcx]
call qword ptr [rax+10h]
----
"mov rcx, rax" is "0x48 0x8B 0xC8" compared to
"mov rax, [rcx]" which is "0x48 0x8B 0x01".
No extra machine code "bloat" in any callers. The extra 1 memory read
is irrelavent if we are about to call malloc() or any of these other
WinOS kernel32.dll syscalls. iperlsys.h/perlhost.h does NOT hook anything
super perf critical such as "memcmp()" or "memcpy()".
- Provide an _asciiopen_ and _asciiopen3_ pair of functions for opening
files on z/OS. These services do a standard open and then, if the
open is successful, update the CCSID of the file descriptor to 819
(ASCII) iff the oflag has ``O_CREAT`` set (e.g. a file is being
created). We could consider printing out a warning if a file is
untagged - right now this will _work correctly_ if the file in
encoded as ASCII (CCSID 819) but will fail if the file is EBCDIC.
- Provide a wrapper _Perl_mkstemp_cloexec_ which not only creates a
temporary file using mkstemp but will also tag the file as CCSID 819.
The tagging is only performed if ``__CHARSET_LIB == 1``, i.e. the
code is compiled with -qascii.
- Define _PerlIO_open_ and _PerlLIO_open3_ as _asciiopen_ and
_asciiopen3_ respectively, when the code is built for ASCII ``#if
(__CHARSET_LIB == 1)`` on z/OS ``#if defined(OEMVS)``.
This just detabifies to get rid of the mixed tab/space indentation.
Applying consistent indentation and dealing with other tabs are another issue.
Done with `expand -i`.
* vutil.* left alone, it's part of version.
* Left regen managed files alone for now.
The API used requires Windows Vista or later.
The API itself requires either elevated privileges or a sufficiently
recent version of Windows 10 running in "Developer Mode", so some
tests require updates.
The previous commit added a mutex specifically for protecting against
simultaneous accesses of the environment. This commit changes the
normal getenv, putenv, and clearenv functions to use it, to avoid races.
This makes the code simpler in places where we've gotten burned and
added stuff to avoid races. Other places where we haven't known we were
getting burned could have existed until now. Now that comes
automatically, and we can remove the special cases we earlier stumbled
over.
getenv() returns a pointer to static memory, which can be overwritten at
any moment from another thread, or even another getenv from the same
thread. This commit changes the accesses to be under control of a
mutex, and in the case of getenv, a mortalized copy is created so that
there is no possible race.
Currently, whether the OS-level signal handler function is declared as
1-arg or 3-arg depends on the configuration. Add explicit versions of
these functions, principally so that POSIX.xs can call which version of
the handler it wants regardless of configuration: see next commit.
There are a bunch of places in core that do
#if defined(HAS_SIGACTION) && defined(SA_SIGINFO)
to decide whether the C signal handler function should be declared with,
and called with, 1 arg or 3 args.
This commit just adds
#if defined(HAS_SIGACTION) && defined(SA_SIGINFO)
# define PERL_USE_3ARG_SIGHANDLER
#endif
Then uses the new macro in all other places rather than checking
HAS_SIGACTION and SA_SIGINFO. Thus there is no functional change; it just
makes the code more readable.
However, it turns out that all is not well with core's use of 1-arg
versus 3-arg, and the few commits will fix this.
From the code comments:
This is an alias for the OS's siginfo_t, except that where the OS
doesn't support it, declare a dummy version instead. This allows us to
have signal handler functions which always have a Siginfo_t parameter
regardless of platform, (and which will just be passed a NULL value
where the OS doesn't support HAS_SIGACTION).
It doesn't actually do anything useful yet, but will shortly allow
signal handler functions to be rationalised.
-the first arg of win32_get_privlib is not used if the registry is not
queried, create a macro to allow the arg to drop out on WIN32_NO_REGISTRY
builds for efficiency and not to have unused C litteral strings in the
binary
-This patch changes the ABI of
PerlEnv_lib_path/PerlEnvLibPath/win32_get_privlib between USE_NO_REGISTRY
and no USE_NO_REGISTRY. Since win32_get_privlib is not exported from
perl523.dll, assume it and PerlEnv_lib_path are not public API, note
technically PerlEnv_lib_path will be callable only on PERL_IMPLICIT_SYS
builds, on no PERL_IMPLICIT_SYS builds it will fail at link time since
win32_get_privlib isnt exported. Therefore place it in
non-[affecting]-binary compatibility even though it does affect binary
compatibility.
-delay load advapi32.dll to save startup time (loading the DLL and the DLL
calling its initializers in DllMain) and one 4 KB memory page for
advapi32's .data section (doing "perl -E"sleep 100" on WinXP shows
advapi32 has a 20KB long .data section, first 4 KB are unique to the
process, the remaining 16KB are COW shared between processes according
to vmmap tool), putting a DebugBreak() in pp_getlogin and doing a
"nmake all" shows miniperl never calls getlogin during the build process.
An nmake test shows only ext/POSIX/t/wrappers.t and lib/warnings.t execute
pp_getlogin. Keeping advapi32.dll out of the perl process requires
removing comctl32.dll, since comctrl32.dll loads advapi32.dll, from perl
which I always do as a custom patch.
filed as [perl #123658]
XXXXXXXXXXXXXXXXXXXXXXX
The following was produced for every non-miniperl object built,
including for XS modules and the test builds done by
ExtUtils::MakeMaker etc
..\iperlsys.h:640:66: warning: 'struct utimbuf' declared inside parameter list
typedef int (*LPLIOUtime)(struct IPerlLIO*, const char*, struct utimbuf*);
^
..\iperlsys.h:640:66: warning: its scope is only this definition or declaration,
which is probably not what you want
An empty cpan/.dir-locals.el stops Emacs using the core defaults for
code imported from CPAN.
Committer's work:
To keep t/porting/cmp_version.t and t/porting/utils.t happy, $VERSION needed
to be incremented in many files, including throughout dist/PathTools.
perldelta entry for module updates.
Add two Emacs control files to MANIFEST; re-sort MANIFEST.
For: RT #124119.
Otherwise the VMS C++ compiler mangles it and we get a link
failure.
And while we're there we can eliminate some PerlIO workarounds
for problems in long-defunct versions of the CRTL.
The same logic but with more safety checks is already defined for
PerlSIO_ungetc in iperlsys.h, so DRY says we should just use that.
Also, that definition in iperlsys.h really depends on the library
we are using, not the compiler. And there is only one viable C
library on VMS and it ships with the OS, so it's really just an
OS dependency.
N.B. While it may be something of a fool's errand to maintain the
stdio layer, deleting redundant code can only be a good thing,
possibly enabling further refactoring and clean-up.
The code dealt rather inconsistently with uids and gids. Some
places assumed that they could be safely stored in UVs, others
in IVs, others in ints; All of them should've been using the
macros from config.h instead. Similarly, code that created
SVs or pushed values into the stack was also making incorrect
assumptions -- As a point of reference, only pp_stat did the
right thing:
#if Uid_t_size > IVSIZE
mPUSHn(PL_statcache.st_uid);
#else
# if Uid_t_sign <= 0
mPUSHi(PL_statcache.st_uid);
# else
mPUSHu(PL_statcache.st_uid);
# endif
#endif
The other places were potential bugs, and some were even causing
warnings in some unusual OSs, like haiku or qnx.
This commit ammends the situation by introducing four new macros,
SvUID(), sv_setuid(), SvGID(), and sv_setgid(), and using them
where needed.
# New Ticket Created by (Peter J. Acklam)
# Please include the string: [perl #81904]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=81904 >
Signed-off-by: Abigail <abigail@abigail.be>
Brings it in line with the rest of the PerlStdIO* functions that
accept parameters in the same order as the corresponding PerlSIO_*
macros. See also commit ecc880cc.
They should have the same prototype as in stdio.
This "proper fix" replaces the 5.12.0 compatible fix in commit 634b482,
but cannot be integrated into 5.12.1 because it breaks binary compatibility.
See also http://rt.perl.org/rt3/Public/Bug/Display.html?id=72704
Arguments to fputc() and fputs() are reverted on Windows.
This is not the optimal patch, but will be backwards compatible
with what is in 5.12.0. For the "correct" patch please see
http://rt.perl.org/rt3/Public/Bug/Display.html?id=72704
Fixes a warning brought about by change #25941 (which made the
filename argument const).
The various implementations of PerlLIOUtime() (in NetWare/, win32/
and wince/) already take a const filename.
p4raw-link: @25941 on //depot/perl: e96b369dc61077fe31b75895167f55dbce4d7519
p4raw-id: //depot/perl@25945
That fact that it wasn't const already was highlighted by a warning
from pp_open_dir() generated by change 24743. Rather than undo the
const change in pp_open_dir(), this seems to make more sense. Hope I
haven't broken Netware or WinCE.
p4raw-id: //depot/perl@24974
note that this change will break binary compatibility with the
default 5.8.0 build options; nevertheless I think it is worth
having in 5.8.1 (people who want the compatibility can disable
the option in the makefile)
p4raw-id: //depot/perl@18327
do_exec parts elided so that change is restricted strictly to
windows; binary compatibility stubs not needed)
p4raw-link: @17568 on //depot/maint-5.6/perl: 07691bcd6c6d7fd92f508fd5268e700370ea47c2
p4raw-id: //depot/perl@17570
* support for building it in the regular makefiles
* large files support via the _*i64() functions (this should be
portable to the 32-bit universe too, but quite untested and
and binary-incompatible, therefore not enabled there)
* three additional test failures in addition to the t/end.t one
(see README.win32)
* sprintf() on Windows gets %I{32,64,}[xoud] format that parallel
the ones available from the CRT (needed because Perl uses
the UVxf macros in both sprintf() *and* in sv_catpvf() et al.)
* add a few 64-bit notes to README.win32
The following general problems were also fixed:
* s/struct stat/Stat_t/g
* Data::Dumper had some naughty 'long' typecasts
* Errno_pm.PL didn't work safe when winsock.h was not in the same
directory as errno.h
* various tell/seek things were incorrectly prototyped
* squelch ugly looking noise when running tests
* Embed.t wasn't linking in all the libraries
* perl57.dll is now perl58.dll (anticipating 5.8.0-RC1)
* re-enable all the disabled warnings (additional fixes may be
needed for the warnings uncovered by this)
p4raw-id: //depot/perl@16033
final touches to the audit for statics and thread-unsafe code
* make DB_File, ODBM_File thread-safe
* remove unnecessary/dangerous statics and protect others
from not getting accidentally enabled under threaded perls
windows support functions get_childdir() et al aren't exported
correctly under vanilla build
Testing under win32 appreciated since changes there had
to be manually merged and I cannot test how badly did I do.
p4raw-link: @12268 on //depot/perlio: bb407f0b8769c638c05e60ebfd157a1e676a6c22
p4raw-id: //depot/perl@12678
p4raw-integrated: from //depot/maint-5.6/perl@12677 'copy in'
win32/vmem.h (@5902..) 'merge in' ext/DB_File/DB_File.xs
(@8693..) win32/win32iop.h (@8917..) ext/ODBM_File/ODBM_File.xs
(@8995..) iperlsys.h (@9154..) scope.c (@9584..) makedef.pl
(@11425..) gv.c (@12026..) op.c (@12145..) util.c (@12220..)
toke.c (@12550..) ext/B/B.xs ext/File/Glob/Glob.xs
ext/Opcode/Opcode.xs ext/re/re.xs (@12653..) mg.c win32/win32.c
(@12668..)
