| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a bug report for perl from neeri@iis.ee.ethz.ch
For each %x element to be inserted, sv_vcatpvfn grows the sv to SvLEN +
the size of the element. I strongly suspect that this is a typo, as this
totally defeats the purpose of the sv_grow buffering and leads to huge
sv's with most memory unallocated.
I have included a patch that I believe to be correct; I am not 100% sure
whether the "+1" is needed, too, but I suspect that it is.
As an aside, from my past two bug reports, I'm starting to believe that
it might be worthwhile to add monitoring of memory consumption to the
execution of the perl test suite: I noticed the bug when the execution of
the seemingly innocuous comp/colon.t failed with an out of memory error
attempting to allocate a huge (>10M) sv. I assume that the execution of
comp/colon.t on an UNIX system would consume just as much memory, but is
not usually noticed because a VM system can easily absorb this. Adding
memory consumption figures to the test reports, if this is possible to do
in a portable way, might uncover more bugs like this.
p5p-msgid: 199706211521.RAA12778@solar.ethz.ch
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apologies if you see this twice, but I'm afraid my first attempt
fell into a black hole. Neither Achim's archive nor the NNTP
gateway seem to have recieved it.
If one tries to compile perl with all of
-DPACK_MALLOC -DHIDEMYMALLOC -DUSE_PERL_SBRK -DPERL_SBRK_VIA_MALLOC
then it's almost certain that miniperl will overflow the C stack on
its first attempt to call malloc().
This happens because with -DPACK_MALLOC Perl_malloc() expects sbrk()
to return 2K-aligned blocks and Perl_sbrk() provides the same sort
of alignments as the system malloc(), i.e. 8 bytes or so.
When Perl_malloc() notices the block returned by sbrk() isn't properly
aligned, it tries to croak("panic: Off-page sbrk"). Croak() calls
mess(); mess() calls mess_alloc(); mess_alloc() calls Perl_malloc();
Perl_malloc() again calls croak() and so on until the C stack overflows.
I see two problems here;
1. With -DPACK_MALLOC, Perl_sbrk() should return 2K-aligned blocks.
2. croak() should not recurse infinitely.
The patch below deals with #1. I'll think some more about #2.
p5p-msgid: 199706240050.CAA10550@xs2.xs4all.nl
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subject: Re: More info regarding the Can't locate error message [PATCH]
lvirden@cas.org (Larry W. Virden) writes:
> use FileHandle;
> STDERR->open("/tmp/errorsfile","w");
This patch tries to fix the problem by auto-blessing handles as
'FileHandle' if the FileHandle package has been loaded and IO::Handle
otherwise. The snag is that STDOUT, STDIN, STDERR are initialized
before 'use FileHandle' executes, so they are all initially blessed as
IO::Handles. We compensate by reblessing them in FileHandle.pm:
This makes Larry's example as well as the following code work:
use FileHandle;
open(F, "/dev/null") or die;
F->seek(0, 1) or die;
p5p-msgid: hyb80drrz.fsf@bergen.sn.no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In article <199706260526.XAA01060@lunkwill.ml.org> Jason wrote:
:This script causes Perl to dump core with a segmentation fault under
:Linux as well as HP-UX. Here's the script:
:
:#!/usr/local/bin/perl
:@justalist = ("foo\nbar" =~ /(\s|(foo)|(bar))*/ );
It does the same under 5.004_01. The reason is that on the second match
it tried to match (foo) and succeeded, leaving startp[2] and endp[2]
pointing to the beginning and end of the matched 'foo'. On the third
match, it tried to match (foo) and failed; in doing so, it overwrote
startp[2] with the startpoint it was trying to match ('bar'), but left
endp[2] unaltered.
If that third match had failed, no problem would occur - it would
restore startp[] and endp[] from saved copies. However, because the
third match then succeeded on the final alternate the modified
startp[] and endp[] were retained, leaving a mismatched pair of values
for $2.
The solution depends on what the answer should be - one interpretation
is that, since (foo) failed to match the last time it was tried, the
results should be ('bar', undef, 'bar'). The first patch below effects
this. Alternatively, you could say that it was more correct and/or
more useful for it to return the last successful match on (foo), in
which case you want the rather more complicated second patch below.
I'm not an expert on this stuff - Ilya, can you take a look at these
patches and tell me how broken they are, please?
My own feeling is that the second interpretation is more useful, but
I have much less confidence in the completeness of my patch for this.
No test cases supplied at this stage: Jason's testcase above should
suffice for the moment. Perl passes all tests here with either patch.
p5p-msgid: 199706261236.NAA03472@crypt.compulink.co.uk
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Hugo van der Sanden <hv@crypt.compulink.co.uk> wrote
> I find this form:
>
> if (ref($from) &&
> (UNIVERSAL::isa($from,'GLOB') || UNIVERSAL::isa($from,'IO::Handle'))) {
>
> really ugly. Has it been determined that UNIVERSAL can't simply be fixed in
> a way that avoids propagating the import?
I agree it's not very pretty. But my feeling is that this is something you
don't do very often. The File:: modules are something of a special
case, because of all the GLOB vs ref GLOB vs FileHandle vs IO:: stuff.
The four examples displayed in my patch really ought to be wrapped up
in some central routine, perhaps in IO::Handle.
My original message suggested two alternative methods.
I think (3) Kludge it is too disgusting to contemplate, but it's easy
enough to do. Perhaps someone can suggest a more elegant variant of the
theme.
I was originally in favour of (4) Hide it, but I've since observed
that the PODs are full of suggestions that you can add a method
to _all_ classes by defining UNIVERSAL::method. Which pretty much rules
out hiding.
> I also still feel that $object->isa('UNIVERSAL') should be true for any
> blessed reference - I tried asking about this a few times before, but
> never received an answer. As it currently stands, it will be true only
> if UNIVERSAL has been explicitly added to the package's @ISA, which to
> my mind should have no effect at all.
How quaint! I can't say I'd noticed that anomaly in my poking about.
The attached patch fixes that. It also radically extends the tests
for UNIVERSAL.
(The new tests assume that my patch to UNIVERSAL.pm has been done.)
p5p-msgid: E0whfHh-0007bW-00@ursa.cus.cam.ac.uk
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Mon, 30 Jun 1997 13:26:33 EDT, Kenneth Albanowski wrote:
>[GIMME after perl_call*() coredumps]
>Is perl_call_sv mucking with the current op? That's the only problem that
>looks vaguely reasonable.
op will be null after perl_call_sv(), and GIMME looks in op to
find the context. I tend to use GIMME only in the declaration
initializers, so have never run into this trap before.
I recommend this patch.
p5p-msgid: 199706301829.OAA05426@aatma.engin.umich.edu
private-msgid: 199706301842.OAA05569@aatma.engin.umich.edu
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Tue, 01 Jul 1997 09:44:49 BST, "M.J.T. Guy" wrote:
>Gurusamy Sarathy <gsar@engin.umich.edu> wrote
>> (BTW, Perl's intolerance of a space between "print" and the
>> opening paren under -w is quite annoying.)
>
>It may be annoying, but whenever I encounter it, it's _always_ telling me
>about an error.
At least not in these cases:
perl -we "print (1)"
perl -we "print (1) if 1"
perl -we "print (1) unless 0"
perl -we "print (1) while 0"
The attached patch carries the kludge a little farther to
avoid warnings in the last three cases.
p5p-msgid: 199707011421.KAA15836@aatma.engin.umich.edu
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Gurusamy Sarathy <gsar@engin.umich.edu> writes:
> On 01 Jul 1997 20:49:15 +0200, Gisle Aas wrote:
> >The following patch (relative to perl5.004) makes this bug go away.
> >Perl still passes all it's tests and the original example works as it
> >did in perl5.003.
> >
> >--- sv.c.orig Tue Jul 1 20:26:40 1997
> >+++ sv.c Tue Jul 1 20:38:13 1997
> >@@ -1713,6 +1713,7 @@
> > sv_upgrade(sv, SVt_PVIV);
> > olderrno = errno; /* some Xenix systems wipe out errno here */
> > sv_setpvf(sv, "%Vd", SvIVX(sv));
> >+ SvIOK_on(sv); /* it is still valid */
> > errno = olderrno;
> > s = SvEND(sv);
> > }
>
> That should restore precisely those flags that were active
> before sv_setpvf() was called. eg: the case where {pIOK,NOK,pNOK}
> are set, the resulting SV should have {pPOK,POK,pIOK,NOK,pNOK}
> set.
NOK or pNOK can't be set at this point. The only possibility is that
pIOK is set and not IOK (but I don't know how can I trigger this
condition?)
This patch should then be safer (it also passes all tests):
p5p-msgid: hbu4l96z2.fsf@bergen.sn.no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Sun, 20 Jul 1997 16:02:05 MDT, Dave Carrigan wrote:
>Eval will fail in the following situation:
>
>- eval'ing a string
>- the string represents an anonymous hash
>- the first key of the anon hash is single quoted, and contains an
> embedded single quote escaped with a backslash
>- using the form `` $ref = eval $string ''
>
>The MLDBM module uses this form of eval all the time, so the above
>situation actually has the potential to occur quite often.
>$string2 = "{'a\\'' => 'foo', 'b' => 'bar', 'c' => 'bat'}";
That is one of the cases where the note in perlref (about
disambiguating braces not preceded by anything else) applies.
However, in this particular case, the code that recognizes if
a literal string is the first thing inside the curlies is not
doing a thorough job of it. The attached patch should cure
it.
Note that you'll still need to write C<eval "{ $a => 'foo' }">
as C<eval "+{ $a => 'foo' }"> if you want it to evaluate as a
hashref. Perl only auto-disambiguates if the first thing in
the curlies is a literal string followed by a comma or =>.
I'll change MLDBM to conform, for the next release.
p5p-msgid: 199707211753.NAA14940@aatma.engin.umich.edu
|
| |
|
|
| |
p5p-msgid: 199707210519.BAA13785@nielsenmedia.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
MHO, pack("p","foo") should evaluate to a pointer that's valid in the
urrent context. pack("p",undef) should return the NULL value.
urrently, they both produce the error "Modification of a read-only
alue attempted".
This looks pretty easy to fix, so I've prepared a diff against the
5.004_01 distribution. This tests fine on my Linux. I hope I'm not
introducing a memory leak or other ailment...
Credited: Tim Bunce <Tim.Bunce@ig.co.uk>
Credited: Gurusamy Sarathy <gsar@engin.umich.edu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Andreas Klussmann <andreas@infosys.heitec.net> wrote
> using
> $x =~ m:(?:xx):;
> instead of
> $x =~ m:(?\:xx):;
> terminates perl immediatly (not in the debuger) and gives
> Sequence (?
> and nothing more as error message.
This illustrates at least three bugs:
i) The message is truncated because of the "NUL in argument to die"
problem which I reported some time ago (and provided a kludge for
in Carp.pm).
ii) In any case, it would have produced an incorrect error message.
iii) This error and many (most? all?) other parsing errors in regular
expressions cause compilation to be terminated.
The attached patch fixes (i) and (ii) but not (iii). It also extends
the regexp tests to test the error messages generated rather than just
note that an error has occurred.
Additional points which I'll leave to someone else:
a) (iii) needs fixing.
b) I note that many regexp error messages are incorrect, as they quote
the regexp as /(?/ rather than as (e.g.) m:(?: or s:(?::.
c) My understanding of Chip's rework of sprintf was that it now provided
a mechanism for including strings with embedded NULs. Could this
be used to provide a complete fix for (i) rather than kludging each
case as it turns up?
d) I strongly suspect that the regexp tests a\ and 'a\'i
are not doing what the author intended. I've left them so they
say "ok" regardless. (Hint: \' is recognised in a '' string.)
p5p-msgid: E0wtbhv-0005Mm-00@ursa.cus.cam.ac.uk
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the segfaults by extending the prohibition on `local($$x)'
to array and hash dereferences and removing the code that never
worked. It also adds simple test cases and a `through' to the error
message.
The new explanation in perldiag isn't terribly clear, but the old one
told an untruth.
It should be possible to make local([$@%]$x) work by adding a new
SAVEt type, and I'd like to do so in the future, but that certainly
wouldn't be maintenance patch material.
p5p-msgid: m0wsb7J-000EYPC@alias-2.pr.mcs.net
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch I sent a couple of hours ago was not enough. In fact
delimcpy() was used wrongly when splitting PATH on dosish systems: '\\'
is not quoting ';' in PATH.
Fortunately, delimcpy() is used in very few places in the source, and
never with ';' as delimiter - outside of PATH context. So we just fix
delimcpy() when the delimiter is ';'.
Enjoy,
p5p-msgid: 199707181120.HAA03593@monk.mps.ohio-state.edu
private-msgid: 199707191651.MAA04897@monk.mps.ohio-state.edu
|
| |
|
|
|
|
|
|
|
| |
This patch is needed because if you run HP-UX 10 and turn off transition
symlinks then /lib goes away and the workaround for the POSIX problem
(2^5 is not exactly 32) won't. (That workaround should use -L/usr/lib/pa1.1,
not -L/lib/pa1.1 because of the transition link problem)
p5p-msgid: 199706181851.AA093329906@hpcc123.corp.hp.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is my day for building perl on various flavor Concurrent boxes - here's
a minor Configure patch for a different operating system.
Version 5.004_01 seems to build, link, and pass all tests perfectly "out of
the box" on Concurrent's PowerMAX OS, but because marketing keeps changing
the name of the operating system, Configure needs a small patch to recognize
all the possible versions of uname output and pick the right hint file. (I
suppose it would make marketing happier if I renamed powerux.sh to
powermax.sh, but I have the feeling they'll change the name again real soon
now, so I'm just gonna leave the hints file with the name it already has
:-).
I did try this patch, and it seemed to recognize the proper hints file
correctly when I built.
p5p-msgid: 9707301938.AA08352@amber.ssd.hcsc.com
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A buglet in Configure casuses it to not find the 3-argument
form of open(2) on some platforms. The problem is that it
tries to compile open3.c using $cc $cppflags. On a NeXT
with MAB support, this will cross-compile for the first
architecture on the list. If that isn't the architecture
Configure is running on, the resultant binary cannot be run.
This leads Configure to believe that open3 is not available.
P.S. A relevant detail not mentioned in the site configurion
summary below, is that I'm compiling on an HP/PA workstation.
Credited: Andy Dougherty <doughera@newton.phys.lafayette.edu>
p5p-msgid: 9706271816.AA10551@ icgned.icgned.nl
private-msgid: 9706271816.AA10551@icgned.icgned.nl
|
| |
|
|
|
|
|
| |
So that the $Config{cf_time} is in English format.
Technique similar to that of forcing awk to use . as the radix character.
p5p-msgid: 199708061827.VAA09623@alpha.hut.fi
|
| |\
| |
| |
| |
| | |
This merge exists so that the p5p version of the patch and the applied
version are both in the history
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Subject: [PATCH] possible h2ph corrections?
i've been getting a whole bunch of redefined sub warnings from my
sys/termios.ph, so here's a fix (well, i don't get the warnings anymore :)
p5p-msgid: Pine.SV4.3.93.970708143446.23808A-100000@florence.teaching.cs.adelaide.edu.au
|
| |/
|
|
| |
(this is the same change as commit 46f24c54ba4249e3ea156261098960de79140a11, but as applied)
|
| |\
| |
| |
| |
| | |
This merge exists so that the p5p version of the patch and the applied
version are both in the history
|
| | |
| |
| |
| |
| |
| | |
This enables the tests that check $^X, on Win32.
p5p-msgid: 199707250029.UAA02351@aatma.engin.umich.edu
|
| |/
|
|
| |
(this is the same change as commit 6328a546c2df884868793e2912ee3da29f24d71f, but as applied)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Subject: Re: Parser nit: possible [PATCH]
In <199706250602.CAA13384@rio.atlantic.net>, Chip Salzenberg writes:
:According to Hugo van der Sanden:
:> Can anyone explain why the parser code for OROP is different from
:> that for ANDOP? I include a patch for what I think it should be,
:> but I don't understand why all tests succeed both with and without
:> this patch.
:Because OROP is a token that's used for both "or" and "xor",
:whereas ANDOP is specific to the single keyword "and".
Ah, in that case the problem is that 'xor' appears nowhere in the
test suite. Patch below adds 4 new tests that normally succeed; my
previous (erroneous) patch causes the first of them to fail.
p5p-msgid: 199706250730.IAA06097@crypt.compulink.co.uk
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've just upgraded from UnixWare 2.1 to 2.1.2 (*See footnote). I was
supprised to see that I got
d_stdio_cnt_lval='undef'
d_stdio_ptr_lval='undef'
A quick bit of spelunking showed that in the 2.1->2.1.1 upgrade stdio.h
got modified, the _cnt and _ptr fields in FILE* got renamed to __cnt and
__ptr.
Here's a patch to hints/svr4.sh, all tests pass.
p5p-msgid: 199707021230.OAA24230@titanic.AtlanTech.COM
|
| |
|
|
|
|
|
|
|
|
|
| |
This patch is needed to avoid GPFs on calls to getservby*()
on Windows NT, when compiling with the Borland compiler.
The same bug is present on Windows95 when using either
compiler.
The patch simply enables the Windows95 workaround.
p5p-msgid: 199706231654.MAA23276@aatma.engin.umich.edu
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The File::Find module exhibits the following defects:
1) If the top-level directory is a symbolic link to another directory,
the find() and finddepth() functions follow that symbolic link and
traverse that directory. This behavior is both contrary to the way
the real find command works and contrary to the way find() and
finddepth() treat symbolic links that occur lower down in the
directory hierarchy (which aren't followed).
Example:
$ cd $HOME
$ mkdir findbug; cd findbug
$ ln -s /usr usr
$ find usr -print
usr
$ find2perl usr -print | perl
usr
usr/lost+found
usr/tmp
usr/tmp/.zma25637cbbb
...
2) If the wanted() function sets $prune = 1 for a toplevel directory,
the find() function ignores it. It honors $prune for all lower level
directories, but not the toplevel ones. This, too, is contrary to
the way the real find command works.
Example:
$ find /usr -print -prune
/usr
$ find2perl /usr -print -prune | perl
/usr
/usr/lost+found
/usr/tmp
/usr/bin
/usr/man
/usr/etc
/usr/lib
/usr/netdemo
/usr/include
/usr/adm
...
3) If finddepth() is passed a toplevel path that is not a directory, it
fails to set $name before calling the wanted() function. This, too,
is contrary to the way the real find command works.
Example:
$ cd $HOME
$ find /dev/null -depth -print
/dev/null
$ find2perl /dev/null -depth -print | perl
$
The following patch corrects all three defects:
p5p-msgid: 199707040045.RAA24459@mailgate2.boeing.com
|
| |
|
|
| |
private-msgid: 3.0.2.32.19970718095755.00875ba0@stargate.lbcc.cc.or.us
|
| |\
| |
| |
| |
| | |
This merge exists so that the p5p version of the patch and the applied
version are both in the history
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Pod2html does not handle ampersands inside C<> sequences properly.
For example, C<&foo(42);> is translated to <CODE>&foo(42);</CODE>.
This is wrong: the "&" needs to be translated to "&".
p5p-msgid: 199706250057.CAA10162@xs1.xs4all.nl
|
| |/
|
|
| |
(this is the same change as commit cbcd949909e8235878afef51bf24ea843fcacde0, but as applied)
|
| |
|
|
| |
private-msgid: 199707300943.LAA21574@kant.imb-jena.de
|
| |
|
|
|
|
|
|
|
|
|
| |
Following patch allows use of :
my $sock = IO::Socket::INET->new(Proto => 'icmp');
To create an ICMP protocol socket, as use for traditional 'ping'.
On UNIX at least only super-user can do this.
p5p-msgid: 199707041240.NAA21484@pluto.tiuk.ti.com
|
| | |
|
| |\
| |
| |
| |
| | |
This merge exists so that the p5p version of the patch and the applied
version are both in the history
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thank you to Tim Bunce and Tom Phoenix for insights on making the
patched code faster and safer, and pointing out bugs.
What follows is a "fresh patch over the 5.004_01 version". So reverse
the previous patch before adding this one just to be safe.
CHANGES (all recommended by Tim or Tom):
- fixed bug where wrong variable was undef()ined causing attempts to
change back to INET socket to never occur
- setlogsock() now croaks on any value other than 'unix' or 'inet'
- setlogsock() no longer uses pattern matching, but is still
case-insensitive
- updated documentation
p5p-msgid: 33B31342.7EB16A44@sc.maricopa.edu
|
| |/
|
|
| |
(this is the same change as commit 8297ae023be5d5af05b2a7f966169444314ba5aa, but as applied)
|
| |
|
|
|
|
| |
perl -pi -e 's/addresses/addr_list/g' .../Net/hostent.pm
p5p-msgid: 199707082222.QAA24728@elara.frii.com
|
| |
|
|
| |
private-msgid: h205qyijy.fsf@bergen.sn.no
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Nick Ing-Simmons writes:
> > I see two possible solutions:
> >
> > a) correct this on the level of IO.xs (manually check for
> > IoIFP(sv_2io(ST(0)));
>
> I like adding this code to the else branch.
This is almost as you ask:
p5p-msgid: 199707250040.UAA11000@monk.mps.ohio-state.edu
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch below is against the 5.004_01 distribution's xsubpp and
incorporates your changes.
> From: Gurusamy Sarathy <gsar@engin.umich.edu>
>
> On Mon, 30 Jun 1997 03:16:25 EDT, Ilya Zakharevich wrote:
> >John Tobey sent me a remarkable fix for xsubpp bugs with #line
> >directives. I did check a previous version of his patch, and it
> >worked flawlessly, with the only drawback that it did not #line'ized
> >BOOT directives.
> >
> >Today I got his next version, and he claims it now handles BOOT too.
> >I think it may go even to the maintainance track.
>
> Not until the issues below are resolved. I've attached a patch
> that fixes all but one.
I believe it's possible to avoid any subprocesses or shell invocations
by using a tied filehandle.
Getting the output filename right will require restructuring xsubpp's
command line interface and changing MakeMaker, whence my ".c" hack.
Given that the previous xsubpp didn't insert any self-pointing line
directives, I figure it's a gain, though by no means perfect.
The tie idea may improve portability at the expense of length and
complexity. It's worked in my test cases (unlike my last patch, in
which C<splice(@BootCode, 1)> should be C<@BootCode> as you noticed).
However, I feel I'm on thin ice when using TIEHANDLE, and this code
can certainly be smoothed out a bit.
p5p-msgid: 199707010221.CAA01234@remote133
|
| |
|
|
|
|
|
|
| |
I was caught by the following errors in documentation:
Enjoy,
p5p-msgid: 199707222307.TAA08380@monk.mps.ohio-state.edu
|
| | |
|
| |
|
|
| |
p5p-msgid: 199708060732.KAA02675@alpha.hut.fi
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
dumpvar.pl parses stringified references incorrectly when extrovert
class names are used. For example,
x bless {}, '=ARRAY('
will crash the debugger.
Patch (for 5.004_01 or 5.004_02) attached.
p5p-msgid: E0wwAjQ-0004l6-00@ursa.cus.cam.ac.uk
|
| |\
| |
| |
| |
| | |
This merge exists so that the p5p version of the patch and the applied
version are both in the history
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Tim Bunce wrote:
>
> I'd like to be able to use, or tell people to use, a simple command like:
>
> PERL_CONFESS=1 bad_script.pl
Does not work for csh folk - they have to do use env or
do setenv.
> or
> perl -MCarpConfess bad_script.pl
This is a bit like -Mblib - pragma-ish so how about
perl -Mconfess bad_script.pl
> [...]
> Note that the whole point is to have a global effect so an alternate Carp
> module would not be appropriate.
>
> I think I prefer the very small change to Carp.pm.
I think I prefer the very small auxillary module:
Credited: Hugo van der Sanden <hv@crypt.compulink.co.uk>
Credited: Tim Bunce <Tim.Bunce@ig.co.uk>
p5p-msgid: 33E79BE2.4E6F@ni-s.u-net.com
|
| |/
|
|
| |
(this is the same change as commit 948f37eb18dbace1def87d7f9339a75821436acd, but as applied)
|
| |\
| |
| |
| |
| | |
This merge exists so that the p5p version of the patch and the applied
version are both in the history
|
