| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
This fixes the problem described in:
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2005-03/msg00740.html
p4raw-id: //depot/perl@24122
|
|
|
|
|
|
|
|
| |
causing subsequent print/read to hang or misbehave
Patch supplied by Artiom Morozov <artiom@phreaker.net>
in the bug report at http://rt.perl.org/rt3/index.html?q=24269
p4raw-id: //depot/perl@23200
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CC: perl-win32-porters@listserv.ActiveState.com
Message-ID: <40F6B295.8010804@uk.radan.com>
Assumes perl's malloc can now handle non-contiguous memory (believed
to be true).
Does not address threading issues.
"The attached patch (against blead) makes sbrk() initially try to
extend the existing block of memory exactly as it currently does, but
to not fail immediately if it can't -- it now frees up that part of
whatever it had previously reserved+committed which hadn't actually
been used yet, resets all its static variables and basically starts
anew."
p4raw-id: //depot/perl@23128
|
|
|
| |
p4raw-id: //depot/perl@23111
|
|
|
|
|
| |
Message-ID: <611491036.20040428001955@ua.fm>
p4raw-id: //depot/perl@22789
|
|
|
|
|
|
|
| |
of 5.8.3
Message-ID: <vm7p70h7au8unrnq4jp85oich7n71ar5ab@4ax.com
p4raw-id: //depot/perl@22691
|
|
|
|
|
| |
Message-ID: <8lgn409p4k2kpde8d428d7a4r7fsgjc8b4@4ax.com>
p4raw-id: //depot/perl@22466
|
|
|
|
|
| |
(by Steve Hay)
p4raw-id: //depot/perl@22431
|
|
|
|
|
|
| |
From: "Kevin Chase" <kevincha99@hotmail.com>
Message-ID: <BAY2-F90usv0ccZRh8Z0005683d@hotmail.com>
p4raw-id: //depot/perl@21992
|
|
|
| |
p4raw-id: //depot/perl@21990
|
|
|
|
|
|
|
| |
From: "Nigel Sandever" <njsandever@hotmail.com>
Message-ID: <Law9-F94BdsnvUFcxT500000ea5@hotmail.com>
Date: Thu, 25 Sep 2003 21:49:07 +0000
p4raw-id: //depot/perl@21989
|
|
|
|
|
| |
Message-ID: <ite8jvgjgcfm8e9dhl6f4dtstrbmn1vmpk@4ax.com>
p4raw-id: //depot/perl@20572
|
|
|
|
|
| |
Message-ID: <9gsnivssuml394bttjb3mfsmdgfn9l6kh9@4ax.com>
p4raw-id: //depot/perl@20455
|
|
|
|
|
| |
Message-ID: <i06eivs0h9khken8rloevj68iqu6n45hnq@4ax.com>
p4raw-id: //depot/perl@20331
|
|
|
|
|
| |
Message-ID: <Mahogany-0.64.2-1016-20030703-160523.00@rbnet.it>
p4raw-id: //depot/perl@19965
|
|
|
| |
p4raw-id: //depot/perl@19673
|
|
|
|
|
|
| |
#19655, #19418; File::Temp no more used internally.
Some parts of these will be salvaged later.
p4raw-id: //depot/perl@19670
|
|
|
|
|
|
|
| |
a spot that had a hardcoded dependency on the cmd.exe
arguments being "/x/c" or "/c"
p4raw-link: @19628 on //depot/perl: 7b24c8f3b02202da900623391393234a869d1b34
p4raw-id: //depot/perl@19668
|
|
|
|
|
|
|
|
|
|
| |
reuse the straightforward native implementation instead
this fixes the warning from io_xs.t
NOTE: File::Temp has a less-than-robust implementation on windows
that relies on END blocks being run (this may not happen always)
p4raw-id: //depot/perl@19667
|
|
|
|
|
| |
p4raw-link: @19628 on //depot/perl: 7b24c8f3b02202da900623391393234a869d1b34
p4raw-id: //depot/perl@19666
|
|
|
|
|
| |
Message-ID: <dv06dv48900iqv5hqddmbc6vt0efvto8d6@4ax.com>
p4raw-id: //depot/perl@19628
|
|
|
|
|
|
|
|
| |
in terms of an exported function rather than as an inlined
macro (latter wants PL_op_mutex which isn't exported as such)
Jarkko: please merge into maint-5.8
p4raw-id: //depot/perl@19484
|
|
|
|
|
| |
Message-Id: <200305020051.43166.abe@ztreet.demon.nl>
p4raw-id: //depot/perl@19384
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[ 19033]
file test operators weren't doing the right thing if the SV
passed to them wasn't NUL-terminated
[ 19034]
ensure SVs returned by Win32::Get{Short,Full}PathName() are
NUL-terminated
p4raw-link: @19034 on //depot/maint-5.6/perl: d453a28c5f70420dd114c2f0f61ec1aaf34109e0
p4raw-link: @19033 on //depot/maint-5.6/perl: 1ad7974d3a92321c870ce2bd5ce4e57098b51c10
p4raw-id: //depot/perl@19036
p4raw-integrated: from //depot/maint-5.6/perl@19028 'merge in' doio.c
(@16333..) win32/win32.c (@18377..)
|
|
|
|
|
| |
Message-Id: <200212140132.gBE1Vxp02090@smtp3.ActiveState.com>
p4raw-id: //depot/perl@18408
|
|
|
|
|
|
|
|
|
|
| |
change#17566 needs to be more defensive about win32_dup2()
itself calling SetStdHandle() (at least MSVCRT does this)
p4raw-link: @18377 on //depot/maint-5.6/perl: 0da6bbac9a33d465c32cde5247be045d49864a2d
p4raw-link: @17566 on //depot/maint-5.6/perl: c7efefc2a43b65746e10207fe89bc47b7f7c27ea
p4raw-id: //depot/perl@18378
p4raw-integrated: from //depot/maint-5.6/perl@18376 'merge in'
win32/win32.c (@18329..)
|
|
|
| |
p4raw-id: //depot/perl@18328
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
Message-ID: <3DB00CB9.70708@alianwebserver.com>
p4raw-id: //depot/perl@18046
|
|
|
|
|
| |
Still imcomplete. Configure will follow
p4raw-id: //depot/perl@18030
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on windows, ensure child processes that get run via backticks get
the right pipe handle at stdin/stdout; this is needed to make
subprocesses see the correct standard handles such that backticks
and piped open()s work when run from within GUI applications
this also makes it possible to launch wperl.exe in backticks
from within an application that has no std handles without a
new blank console window popping up
p4raw-link: @17566 on //depot/maint-5.6/perl: c7efefc2a43b65746e10207fe89bc47b7f7c27ea
p4raw-id: //depot/perl@17567
|
|
|
|
|
|
| |
cases as well, and make any future unknown ones show up as
unknown(0x123).
p4raw-id: //depot/perl@17064
|
|
|
| |
p4raw-id: //depot/perl@16507
|
|
|
|
|
|
| |
in one place, assuming we want to re-CPAN Time::HiRes at
some point.
p4raw-id: //depot/perl@16506
|
|
|
|
|
| |
from perl
p4raw-id: //depot/perl@16503
|
|
|
| |
p4raw-id: //depot/perl@16462
|
|
|
| |
p4raw-id: //depot/perl@16461
|
|
|
| |
p4raw-id: //depot/perl@16460
|
|
|
|
|
|
|
|
|
|
| |
English.t seems to fail on an errno test, and socketpair blathers
about something.
Basic fix is to stop PERL_IMPLICIT_SYS turning on USE_PERLIO by the
back door, and instead have perlsdio.h vector stdio via iperlsys.h
function tables (latter was done in earlier change).
Update comments in Makefile.mk
p4raw-id: //depot/perlio@16367
|
|
|
|
|
|
| |
- move body of fdupopen() from perlhost.h to win32.h as win32_fdupopen()
- use it in perlio.c
p4raw-id: //depot/perlio@16349
|
|
|
|
|
| |
when all three stdhandles are invalid (from Jan Dubois)
p4raw-id: //depot/perl@16062
|
|
|
|
|
|
| |
change is from change#12026)
p4raw-link: @12026 on //depot/maint-5.6/perl: ff42b73b40f5a895aef4bed81c794f468e0609bc
p4raw-id: //depot/perl@16048
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
| |
Message-ID: <85256B9E.0064EBE9.00@btg_hub01.bombardier.com>
p4raw-id: //depot/perl@15985
|
|
|
|
|
|
| |
From: "Konovalov, Vadim" <vkonovalov@spb.lucent.com>
Message-ID: <845FCFF2D4C0FC468B485E8777C7A00C028116@cio-test001.spb.lucent.com>
p4raw-id: //depot/perl@15982
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win32::GetLongPathName() did not return valid results if there
were "." and ".." components in the path; also fix a potential
buffer overflow if the long path happens to be longer than
MAX_PATH (this can presumably happen if they use \\?\... style
paths); add a rather limited testsuite that exercises just the
edge cases
p4raw-link: @15879 on //depot/maint-5.6/perl: a15439704ef1059bf178ec4b1820fee7b2af7173
p4raw-id: //depot/perl@15880
p4raw-branched: from //depot/maint-5.6/perl@15877 'branch in'
t/win32/longpath.t
p4raw-integrated: from //depot/maint-5.6/perl@15877 'ignore' MANIFEST
(@12747..) 'merge in' t/harness (@11427..) win32/win32.c
(@13145..)
|
|
|
|
|
|
| |
From: "Mattia Barbon" <mbarbon@dsi.unive.it>
Message-ID: <3C9B57B0.31936.496399@localhost>
p4raw-id: //depot/perl@15517
|
|
|
|
|
|
|
| |
Message-ID: <AIEAJICLCBDNAAOLLOKLEEEAEAAA.paul_marquess@yahoo.co.uk>
packWARN also for subdirs.
p4raw-id: //depot/perl@15378
|
|
|
|
|
|
|
| |
Message-ID: <179381153.20020224103125@tesla.rcub.bg.ac.yu>
(the pid half only)
p4raw-id: //depot/perl@14867
|