Duplicates in perlguts.pod

Seven entries in the API listing at the end of perlguts.pod are duplicated:

p5p-msgid: 9707082346.AA13231@ icgned.icgned.nl
private-msgid: 9707082346.AA13231@icgned.icgned.nl

work around compiler bug on CX/UX (perl5.004_01)

This patch provides a work-around for a compiler bug on CX/UX systems (which
shows up as a failure in the 'w' format of pack). The
CXUX_BROKEN_CONSTANT_CONVERT ifdef flag is added to the hints/cxux.sh
compiler and pp.c is modified to avoid a compile time constant conversion
which fails based on that ifdef.

While I was in the hints file, I also added the magical
-Qtarget=M88110compat compiler option which makes it build code that will
run on both 88110 and 88100 CX/UX machines interchangably.

This patch was generated from a brand new copy of perl5.004_01, so I'm
confident there are no extraneous changes that slipped in. I even built
and tested and it passed all tests.

(I decided to go with option #3 in my previous mail about how to do the patch).

If its too late for 5.004_02, I wouldn't worry - it isn't very critical.

p5p-msgid: 9707301934.AA18594@amber.ssd.hcsc.com

Fwd: substr("foo", -1000)

Subject: hmmm.

Isn't it weird that

substr("foo", -1000)

is silently converted to substr("foo", 0, 3) while

substr("foo", 1000)

always causes RETPUSHUNDEF and possibly a warning?  I'd say there's
too much code in pp.c:pp_substr.

Credited: Jarkko Hietaniemi <jhi@iki.fi>
Credited: Tim Bunce <Tim.Bunce@ig.co.uk>

p5p-msgid: 9707072304.AA01069@toad.ig.co.uk
private-msgid: 199707100655.JAA14924@alpha.hut.fi

semctl broken under Linux

semctl(...,[GS]ETALL,...) passes an uninitialized pointer to the syscall.

Credited: Graham Barr <gbarr@ti.com>
Credited: Tim Bunce <Tim.Bunce@ig.co.uk>

p5p-msgid: 9707040912.AA03470@issan.informatik.uni-dortmund.de
private-msgid: 33C38291.2D9302DA@ti.com

Enable PERL_DEBUG_MSTATS without -DDEBUGGING_MSTATS

Subject: [PATCH]: reduced malloc patch

Since this problems arise again and again on the list, here is the
reduced malloc patch.  It corrects the following problems:

a) several off-by-one in av_make();
b) Growing TMP on conversion number=>string;
c) Uncompatibility of -DDEBUGGING_MSTATS and system malloc;

(The first two problems are fixed by malloc_jumbo_2 as well, but the
2 chunks for "c" - in perl.c - were forgotten in that patch).

Enjoy,

p5p-msgid: 199707150829.EAA01291@monk.mps.ohio-state.edu

Re: q and escaping paired delimiters

On Sun, 27 Jul 1997 19:57:31 EDT, Kenneth Albanowski wrote:
>In fact, the code in toke.c looks a little suspicious, as if a cut'n'paste
>error happened, and the balanced branch didn't get the cleanup it
>deserved. There's a "if term != '\\'" statement that does nothing, for
>example.

Keen. That same deadcode was in one of my post 4_01 patches
too (it does no damage, but like you say it serves no purpose
either).

>Here'a patch over 5.004_01 (although I'd expect it to work with most
>versions) to allow you to escape both the starting and end quotes for q
>(unbalanced and qq is unchanged), and the obligatory addition to the
>tests. If nobody has any complaints, I expect this will be in _02.

The toke.c hunk is "dangerous", in the sense that GNU patch will
apply it to the wrong branch, if it needs to offset the patch
due to later patches having been applied.  This is thanks to
the two branches having the exact same 8 lines of code.

I of course recommend the change you suggest, and to prove
my faith, I attach my own version, which:

   * eliminates the same deadcode in one of my later patches
   * uses the more meaningful names in the balanced branch
   * doesn't provoke the GNU patch problem with inadequate
     context

Credited: Kenneth Albanowski <kjahds@kjahds.com>

p5p-msgid: 199707280516.BAA14055@aatma.engin.umich.edu

Re: q and escaping paired delimiters

On Sun, 27 Jul 1997 chrisn@rock.petersons.com wrote:

> $\ = "\n";
> print '\'this\'';
> print q{'this'};
> print q{{this}};
> print q{\{this\}};
>
> I would expect the output to be:
>
> 'this'
> 'this'
> {this}
> {this}

That this should be fixed makes perfect sense to me. You can view easily
view backwhacking both sides as a generalization of backwhacking the quote
for an unbalanced q''.

In fact, the code in toke.c looks a little suspicious, as if a cut'n'paste
error happened, and the balanced branch didn't get the cleanup it
deserved. There's a "if term != '\\'" statement that does nothing, for
example.

Here'a patch over 5.004_01 (although I'd expect it to work with most
versions) to allow you to escape both the starting and end quotes for q
(unbalanced and qq is unchanged), and the obligatory addition to the
tests. If nobody has any complaints, I expect this will be in _02.

Credited: Gurusamy Sarathy <gsar@engin.umich.edu>

p5p-msgid: Pine.LNX.3.93.970727172201.350K-100000@kjahds.com

-S flag fixes for DOSISH platforms

This patch supercedes the one posted here by Ilya
(Message-Id: <199707191651.MAA04897@monk.mps.ohio-state.edu>).

There are no changes for Unix platforms over Ilya's
version.  On DOSISH platforms, the initial check in
the current directory (or the actual path to the script,
if supplied) includes searching for valid extensions.

The fact that -S does not do a PATH search if the supplied
filename contains directory separators (on all platforms) is
documented.  This behavior is similar to Unix and DOS shells.

Note -S *does* have an effect on DOSISH platforms even if no
PATH search happens: valid extensions will be checked for if
the file name is not found.

p5p-msgid: 199707250043.UAA02385@aatma.engin.umich.edu

$\1 and serious bug in evalling

A bug report of several hours ago (that you cannot enter $\1 in
debugger with some combinations of mallocs and ReadLines) is fixed by
this:

p5p-msgid: 199707262127.RAA12883@monk.mps.ohio-state.edu

Win32 UNC path causes autoload to fail

This is a bug report for perl from wjones@tc.fluke.com,
generated with the help of perlbug 1.17 running under perl 5.004.

p5p-msgid: 97Jun18.163826pdt.35714-1@gateway.fluke.com

Weirdness in sv_peek()

Tom Phoenix writes:
 > On Sat, 26 Jul 1997, Stephen McCamant sent a patch and wrote:
 >
 > > I don't know what to say about this one.
 >
 > Well, it would be nice to tell us what it's supposed to accomplish! :-)

I've given it more thought, and I've thought of something to say. :-)

You've snipped the patch, but here's the gist of it:

Look at sv_peek(), around line 900 of sv.c. What this function does is
build a short description of the contents of an SV, for use in things
like -Ds stack dumps. It starts with an empty SV `t', and appends
various strings to it: the SV's type, its numeric value, etc. When
it's done, it returns the char * (PV) value of the SV. On line 955,
one case in the switch that has the type name ends in `return
tokenbuf'. tokenbuf is not a local variable, but a global one, not
used anywhere else in the function, that holds the last keyword token
that the lexer scanned. Why would the function return it when the SV
happened to be undefined?

I noticed this `weirdness', as I called it in the subject, when
running perl -Dts on a short program that had a bug in it:

/src/perl5.004_01+% dperl -Dts -e 'for ($x) { map(die, 0) }'

EXECUTING...

    =>
(-e:0)  enter
    =>
(-e:0)  nextstate
    =>
(-e:1)  pushmark
    =>  *
(-e:1)  gvsv(main::x)
    =>  *  die
(-e:1)  gv(main::_)
    =>  *  die   GV()
(-e:1)  enteriter
    =>  die
(-e:1)  iter
    =>  die   SV_YES
(-e:1)  and
    =>  die
(-e:1)  nextstate
    =>  die
(-e:1)  pushmark
    =>  die   *
(-e:1)  const(IV(0))
    =>  die   *  IV(0)
(-e:1)  mapstart
    =>  die   *  IV(0)  ***
(-e:1)  pushmark
    =>  die   *  IV(0)  ****
(-e:1)  die
Died at -e line 1.
Attempt to free unreferenced scalar.

Notice the large number of `die's. If I didn't know better, I'd think
perl was threatening me.

At the time I mailed the patch, the presence of that line in sv_peek()
didn't make any sense at all to me -- a total non sequitur. I
considered writing something about my puzzlement (even checking how to
spell `non sequitur'), but I couldn't think of anything fitting to
say.

In the time since, I've come up with a theory of where that line came
from. I don't have the source for any old 5.0 versions handy, but I
realized I did have a debugging binary of 5.003_07, and it didn't have
the bug. I now think this bug was introduced late in the 5.003_9?
series when Chip decided to fix every buffer overflow he could
find. Specifically, I theorize, sv_peek used to use tokenbuf to hold
the string it was working on, but it was changed to use an SV instead
of a fixed size buffer (that the SV was called `t' was a clue). The
fact that this line wasn't updated can then be chalked up to simple
oversight, and my sense of the order of the universe is intact.

Turns out I can say a lot about this, if I put my mind to it.

p5p-msgid: m0wsEMU-000EYLC@alias-2.pr.mcs.net

Minor Win32 glitch with -S flag

This is a bug report for perl from wjones@tc.fluke.com,
generated with the help of perlbug 1.17 running under perl 5.004.

p5p-msgid: 97Jun19.150511pdt.35717-2@gateway.fluke.com

Fix double form() in XS version check

p5p-msgid: 199707210518.BAA13771@nielsenmedia.com

-p does not check for failure of implicit print

Unlike modern incarnations of, say, awk and sed, perl -p does not check the
return status of the implicit print statement executed for each input
record.

Here's a patch against 5.004_01.  ('ware wrapping: there's a long line
in it.)  There's no test case: I couldn't think up a reliable,
portable and polite way of inducing a write error.

I think, in the specific case of the implicit print in -p, this is
non-controversial, and can go in the maintenance branch.  That's not to say
that there are not programs using -p out there (probably CGI scripts) which
will surprise people by exiting noisily on encountering an error, rather
than continuing to do thewrong thing quietly.  Does anybody know of any
widespread examples?  Do we care?

More controversial error checking patch for implicit close of <ARGV>
to follow in separate bug report.

p5p-msgid: v0311070aafea3fa83061@[194.51.248.75]

sv_vcatpvfn hogs memory [Patch included]

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

infinite recursion in malloc() with some compile flags

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

bless file handles as FileHandle if loaded else IO::Handle

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

Avoid core dump on some paren'd regexp matches

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

UNIVERSAL.pm and import methods (tests)

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

Re: Calling Perl from within C from within Perl

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

Fix intolerance of a space between "print" and opening paren

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

stringify looses integerness

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

Eval fails in certain situations (eval "{'...")

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

Do not constant-fold ops that depend on locale if C<use locale>

p5p-msgid: 199707210519.BAA13785@nielsenmedia.com

Re: Can't pack literals as pointers

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>

Re: Bug in Regular Expressions when using colon as delimiter

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

Band-aid fix for local([@%]$x)

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

Additional patch for "Can't execute ..."

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

: HP-UX 10 w/o transition links

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

make Configure recognize powerux hint (perl5.004_01)

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

Configure can't find open3 on NeXTstep

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

m2t3: Configure: cf_time always in C locale

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

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

h2ph corrections to avoid redefined sub warnings

(this is the same change as commit 46f24c54ba4249e3ea156261098960de79140a11, but as applied)

h2ph corrections to avoid redefined sub warnings

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

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

enable some tests on Win32

(this is the same change as commit 6328a546c2df884868793e2912ee3da29f24d71f, but as applied)

enable some tests on Win32

This enables the tests that check $^X, on Win32.

p5p-msgid: 199707250029.UAA02351@aatma.engin.umich.edu

Add xor tests to test suite

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

fixes for hints/svr4 for UnixWare >= 2.1.1

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

getservby*() calls fail on Windows NT

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

(3) File::Find::find()/finddepth() bugs with toplevel paths

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

posix.xs broken on VMS 7.1

private-msgid: 3.0.2.32.19970718095755.00875ba0@stargate.lbcc.cc.or.us

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

pod2html mangles C<&foo(42);>

(this is the same change as commit cbcd949909e8235878afef51bf24ea843fcacde0, but as applied)

pod2html mangles C<&foo(42);>

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 "&amp;".

p5p-msgid: 199706250057.CAA10162@xs1.xs4all.nl

Allow concurrent mkdir in File::Path::mkpath

private-msgid: 199707300943.LAA21574@kant.imb-jena.de

icmp tweak for IO::Socket

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

ExtUtils-Embed upgrade

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

Sys::Syslog patch to allow unix domain sockets

(this is the same change as commit 8297ae023be5d5af05b2a7f966169444314ba5aa, but as applied)

Sys::Syslog patch to allow unix domain sockets

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

Net::hostent documentation error

perl -pi -e 's/addresses/addr_list/g' .../Net/hostent.pm

p5p-msgid: 199707082222.QAA24728@elara.frii.com

IO::File and DB_File pollutes namespace with Fcntl constants

private-msgid: h205qyijy.fsf@bergen.sn.no

Problems with setvbuf

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

xsubpp patch

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

Docs of IO::Handle [PATCH]

I was caught by the following errors in documentation:

Enjoy,

p5p-msgid: 199707222307.TAA08380@monk.mps.ohio-state.edu

m2t2 broke CPAN.pm :-(

m2t3: minor doc patch (to obsolete I18N::Collate)

p5p-msgid: 199708060732.KAA02675@alpha.hut.fi

[BUG:PATCH] dumpvar.pl parses some references incorrectly

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

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

confessing a carp

(this is the same change as commit 948f37eb18dbace1def87d7f9339a75821436acd, but as applied)

confessing a carp

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

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

Warning from calls using "use Shell"

(this is the same change as commit a5bda13b0ef005fbbd13265a362caff51359bbc6, but as applied)

Warning from calls using "use Shell"

On Mon, 28 Jul 1997 15:35:46 -0400 (EDT), Thomas Lowery
<nab2337@dsacnhp1.dsac.dla.mil> wrote:
>
>Following an example from the perldoc Shell produces the following
>warning messages. How do I avoid the warning?
>
>Variable "$cmd" will not stay shared at (eval 1) line 14.
>Variable "$cmd" will not stay shared at (eval 2) line 14.

Under 5.004, Shell.pm triggers this warning for every sub it autoloads.  I
didn't see any response to this message, so here is a simple patch.  It just
makes the named sub an anonymous sub assigned to a glob, suppressing the
warning.

Credited: Andrew Pimlott <andrew@pimlott.student.harvard.edu>

p5p-msgid: 199708061739.NAA14754@pimlott.student.harvard.edu
private-msgid: Pine.SOL.3.91.970806173903.7320H-100000@abel

splitpod broken in 5.004_01

> From: Hans Mulder <hansmu@xs4all.nl>
>
> Splitpod is broken in 5.004_01.

Darn, my fault.

Thanks for this and your other bug reports. I guess _02 will be
sooner rather than later.

p5p-msgid: 9706241612.AA09119@toad.ig.co.uk

Document use of - in a regex char class.

Subject: [PATCH] Re: regex matcher incorrect

At 13:17 +0200 1997-06-24, Ulrich Windl wrote:
>In a statement like "$_[0] =~ /^([ugoa]+)([+-=])([rwxst]*)$/;" some
>incorrect patterns were matched. As an example "go/rw" was matched.
>Adding a backslash in front of the minus, making "[+\-=]", solved the
>problem.
>
>As this is a non-obvious feature, I'd consider that as a bug. Originally
>the problem was seen on Linux running the same version of Perl.

Thanks Ulrich.  You're right.   While all UNIX-descended regular expression
packages work pretty much the same way in respect how you make "-" a member
of a character class, neither the documentation delivered with Perl nor the
book "Programming Perl" tells you what to do, and they should.  Here's a
patch to apply to the perlre.pod documentation file:

p5p-msgid: v03102804afd578bcef2c@[194.51.248.88]

done3/perlbook.pod

arguments swapped in perlapio.pod

Three PerlIO functions have their arguments swapped (compared with
their stdio counterparts).  Perlapio.pod gets this almost right:

p5p-msgid: 199706240049.CAA10534@xs2.xs4all.nl

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

[BUG:47:LOG] Dropped "and" in pod2man

(this is the same change as commit 5d3b0638f4c2cf44af3831abe68fc08048b89bc2, but as applied)

[BUG:47:LOG] Dropped "and" in pod2man

Nathan Torkington wrote:

> perlfunc.pod contains:

> For a yet-more-powerful import facility, see L</use> and
> L<perlmod>.

> when pod2man | nroff -man  has its way with this, it comes out as:

>                For a yet-more-powerful import facility, see the
>                use entry elsewhere in this document the perlmod
>                manpage.

> That is, the "and" is dropped.  I've verified this with the pod2man
> that comes with 5.004_01, but I couldn't produce a simple test case in
> 30 seconds.

This is about as simple as I could produce in 50 seconds:

=head1 NAME

foo - bar

=head1 DESCRIPTION

L</foo> and bar

This seems to help:

p5p-msgid: 9707082355.AA13254@ icgned.icgned.nl
private-msgid: 9707082355.AA13254@icgned.icgned.nl

Major goof in XS Tutorial regarding subdirs

Subject: [PATCH] Major goof in XS Tutorial (subdirs)

I wondered for a lot of time why I never manage to compile extensions with
debugging enabled if the main Perl library is optimized.  Some time ago
I understood that this is due to the following error in XS tutorial:

p5p-msgid: 199707260920.FAA12453@monk.mps.ohio-state.edu

object never destructs

On Sun, 13 Jul 1997 11:20:24 EDT, Andrew Pimlott wrote:
>package mytest;
>sub DESTROY { warn "Death"; }
>package main;
>{
>    my $joe;
> my $moe;
> $moe = bless \$joe, 'mytest';
> print "Leaving block\n";
>}
>print "Left block\n";

Thanks for that excellent test case.  Perl optimizes the
memory management of lexicals by not actually deallocating
unreferenced lexicals when the block exits, in order to
reuse them when the block is reentered.  This of course
fails to destruct objects at the end of blocks.

A patch that fixes the problem for all object datatypes
is attached.

p5p-msgid: 199707131955.PAA29655@aatma.engin.umich.edu

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

: reduced malloc patch

(this is the same change as commit 38a1ac3f7341206073b47f38b6bdb094f3f50352, but as applied)

: reduced malloc patch

Since this problems arise again and again on the list, here is the
reduced malloc patch.  It corrects the following problems:

a) several off-by-one in av_make();
b) Growing TMP on conversion number=>string;
c) Uncompatibility of -DDEBUGGING_MSTATS and system malloc;

(The first two problems are fixed by malloc_jumbo_2 as well, but the
2 chunks for "c" - in perl.c - were forgotten in that patch).

Enjoy,

p5p-msgid: 199707150829.EAA01291@monk.mps.ohio-state.edu

Constant-fold sprintf()

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

Don't use undef value in Config::myconfig

(this is the same change as commit 754da6387aaed7d7ca907de8ac487143097ad5e3, but as applied)

Don't use undef value in Config::myconfig

Subject: Config->myconfig not -w clean

Thanks to a report by Larry Virden I spotted a bug in Config.pm.
Undefined values trigger "Use of undefined value" messages, e.g.

# perl -MConfig -we 'print Config->myconfig'
Use of uninitialized value at /usr/local/lib/perl5/IP22-irix/5.004/Config.pm line 553.
Use of uninitialized value at /usr/local/lib/perl5/IP22-irix/5.004/Config.pm line 553.
Use of uninitialized value at /usr/local/lib/perl5/IP22-irix/5.004/Config.pm line 553.
Use of uninitialized value at /usr/local/lib/perl5/IP22-irix/5.004/Config.pm line 553.
Summary of my perl5 (5.0 patchlevel 4 subversion 0) configuration:
  Platform:
[...]

I'd suggest this simple patch:

Credited: Chip Salzenberg <salzench@nielsenmedia.com>

p5p-msgid: 199706271525.RAA13517@sissy.in-berlin.de

[differences between cumulative patch application and perl5.004_01]

[editor's note: The changes between this and 5.004 were processed from
the m1t2 release, which was a bad idea as it was the _01 release which
had the final corrected attributions.  The differences between the
various m*t* releases do that; I considered it most valuable just to
look at the _NN releases.  Many patches have been separated out and/or
applied from the p5p archives nonetheless.]

[inseparable changes from changes to perl-5.004_01-mt2]

 BUILD PROCESS

Subject: [PATCH] INSTALL-1.18
From: Andy Dougherty <doughera@fractal.phys.lafayette.edu>
Files: INSTALL
Msg-ID: Pine.SOL.3.95q.970529142739.662D-100000@fractal.lafayette.edu

    (applied based on p5p patch as commit 0dcb58f4e9dab7110393871db954eb94cbf90dd0)

Subject: improved gnuwin32 Configure support
From: Chris Faylor <cgf@bbc.com>
Files: Configure

    private-msgid: 199706070318.XAA09214@hardy.bbc.com

Subject: installhtml problems finding splitpod
From: Larry W. Virden <lvirden@cas.org>
Files: installhtml INSTALL

Subject: oddity in Configure
From: Mike Stok <mike@stok.co.uk>
Files: Configure

Subject: Compiling perl5.004 on NEWS-OS 4.x
From: Makoto MATSUSHITA (=?ISO-2022-JP?B?GyRCJF4kRCQ3JD8kXiQzJEgbKEI=?=) <matusita@ics.es.osaka-u.ac.jp>
Files: Configure hints/newsos4.sh
Msg-ID: 19970521132814F.matusita@ics.es.osaka-u.ac.jp

    (applied based on p5p patch as commit 4e81affe051125c1f0c81f7d518efaa52584a56d)

 CORE LANGUAGE

Subject: first true value returned by scalar C<...> is wrong
From: Hans Mulder <hansm@euronet.nl>
Files: pp_ctl.c t/op/flip.t

Subject: Regex Bug in 5.003_26 thru 003_99a
From: Andreas Karrer <karrer@ife.ee.ethz.ch>
Files: regcomp.h regcomp.c regexec.c
Msg-ID: 199705161915.PAA18721@rio.atlantic.net

    (applied based on p5p patch as commit c8756f30ff24381844a7b05f062074a87dc23910)

Subject: -w interacts badly with -Dt
From: Spider Boardman <spider@Orb.Nashua.NH.US>
Files: sv.c

Subject: No DESTROY on untie. Tie memory leak fixed.
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: pp_hot.c
Msg-ID: 199705172156.RAA20561@aatma.engin.umich.edu

    (applied based on p5p patch as commit 5117ca915f2c72e17e52c313797ad394bd76c418)

Subject: magic_clear_all_env proto should match svt_clear
From: Nick Ing-Simmons <nik@tiuk.ti.com>
Files: proto.h mg.c

Subject: ENV leaks on win32 (was Re: Comments on ENV patch sought)
From: Hans Mulder <hansm@euronet.nl>
Files: embed.h perl.h proto.h global.sym mg.c t/op/magic.t
Msg-ID: 199705292240.AAA01135@mail.euronet.nl

    (applied based on p5p patch as commit 66b1d5575fd5eb6242bac2e9a08b163be8b1b960)

Subject: Patch to show @INC when require dies
From: Jim Avera <avera@hal.com>
Files: pp_ctl.c
Msg-ID: 9705230121.AA27872@membrane.hal.com

    (applied based on p5p patch as commit 2683423cd7aae39c7c67a005320f39d6e84a2f1f)

Subject: bug with m// nested inside s///e
From: Hans Mulder <hansm@euro.net>
Files: op.c t/op/subst.t

 DOCUMENTATION

Subject: perlembed Win32 update
From: Doug MacEachern <dougm@opengroup.org>
Files: pod/perlembed.pod

Subject: perldiag.pod patch - "(W) substr outside string" is "(S)evere" if used as lvalue.
From: John Hughes <john@AtlanTech.COM>
Files: pod/perldiag.pod

Subject: local(%ENV) looses magic - document behaviour
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: pod/perlsub.pod

Subject: perlguts caveats
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: pod/perlguts.pod
Msg-ID: 199705180052.UAA22066@aatma.engin.umich.edu,
199705180202.WAA22826@aatma.engin.umich.edu,
Msg-IDs: 1997May17.235722.2033087@hmivax.humgen.upenn.edu,
 199705301341.JAA05204@aatma.engin.umich.edu

    (applied based on p5p patch as commits:
      04343c6db20ad44e9b9b5531ea62e7099311ed51
      6e2bfd7f4281bd19f5eefda1f130d62ef05c8ead
      9edb2b4665db2ce663d9133a47065be4582a8114)

Subject: pod2man produces broken pages
From: Davin Milun <milun@cs.Buffalo.EDU>
Files: pod/pod2man.PL
Msg-ID: 199705310447.AAA15721@obelix.cs.Buffalo.EDU
Msg-ID: 1997May25.192350.2055977@hmivax.humgen.upenn.edu

    (applied based on p5p patch as commits:
      3ad491548632328bb8df33165fefb8d5b9b7b7a9
      ca023ceb228b064c65630ce565435e433344bfd5)

Subject: Perl 5 pod2man fix
From: Franklin Chen <chen@adi.com>
Files: pod/pod2man.PL

    Subject: perlguts man page corrupted

    perlguts.1 has garbled headings, e.g., the following is a result of
    "man perlguts":

    ===
         What is an

         Perl uses a special typedef IV which is a simple integer
         type that is guaranteed to be large enough to hold a pointer
         (as well as an integer).
    ===

    p5p-msgid: 199705210013.UAA09599@menhaden.adi.com

Subject: reference form chomp to chop in perlfunc
From: Hans Mulder <hansm@euronet.nl>
Files: pod/perlfunc.pod

Subject: pod2man gags if "=pod" is before "=head1 NAME"
From: Warren Hyde <whyde@pezz.sps.mot.com>
Files: pod/pod2man.PL
Msg-ID: 9705212115.AA21730@pezz.sps.mot.com

    (applied based on p5p patch as commit a8aaa22cf27ba31be005a4b638b78d4105203ee9)

Subject: perlfunc.pod unclear about return value range of rand
From: "Tuomas J. Lukka" <tjl@lukka.student.harvard.edu>
Files: pod/perlfunc.pod

    Subject: Re: Array feature request

    Tom Phoenix writes:
    >On Fri, 16 May 1997, Tuomas J. Lukka wrote:
    >
    >> To detract further, the perlfunc.pod says
    >>
    >>  "returns a random fractional number between 0 and EXPR".
    >>
    >> Does that mean inclusive or exclusive i.e. do I run a risk of one
    >> in a billion receiving an undef one past the array limit and growing
    >> the array? If yes or if not, should that be mentioned?
    >
    >           0  <=  rand(EXPR)  <  EXPR
    >
    >Hope this helps!

    Yes, this behaviour is expected but it is definitely not documented
    in the pods.

    p5p-msgid: m0wSMiC-000C9xC@lukka.student.harvard.edu

Subject: Error in perllol manpage
From: Chris Wick <cwick@lmc.com>
Files: pod/perllol.pod

Subject: 5.004 removed deprecated %OVERLOAD support silently
From: Jonathan Biggar <jon@sems.com>
Files: pod/perldelta.pod

    This is a bug report for perl from jon@sems.com,
    generated with the help of perlbug 1.17 running under perl 5.004.

    p5p-msgid: 199705232319.QAA28388@clamp.netlabs.com

Subject: Documentation bugs
From: Stephen Potter <spp@psa.pencom.com>
Files: pod/perldata.pod pod/perldiag.pod pod/perlfaq8.pod pod/perlfaq9.pod pod/perlop.pod pod/perlsub.pod pod/perltoot.pod

Subject: make html --> unusable xref links
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml

    Jim Avera writes:
     > By default (without editing the Makefile) the resulting .html files
     > are useless -- they have broken cross-reference links.
     >
     > If you set HTMLROOT=. in pod/Makefile, then cross-references
     > say .//pod/... which does not work either.
     > Setting HTMLROOT to an absolute path doesn't work either (the
     > spurrious /pod/ is always there).

     [seconded]

    p5p-msgid: 199705162008.XAA06906@alpha.hut.fi

Subject: pod/*.html -- all hyperlinks are invalid
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml

    The INSTALL file says:

     (cd pod && make html && mv *.html <www home dir>)

    But the resulting *.html files have hyperlinks that look like this;

     <A HREF="/pod/perlfaq.html">perlfaq</A>

    The /pod/ part shouldn't be there.  As a result, all of the hyperlinks are
    invalid (unless, of course, you install the *.html files in /pod/).

    [Please do not change anything below this line]

    p5p-msgid: 199705171830.OAA15652@erawan.cognex.com

Subject: Re: make html - any takers?
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml

    On Sat, 07 Jun 1997 02:27:49 -0000, Tim Bunce wrote:
    >My reading of the following is that the best short term fix is for
    >INSTALL to be changed so it no longer suggests
    >
    > (cd pod && make html && mv *.html <www home dir>)
    >
    >Comments welcome. Proven portable and tested patches preferred :-)

    Win32 uses something similar to the suggested method with
    installhtml, and it seems to work reasonably well.  I'll supply
    a patch if I wander anywhere close to a UNIX box in the
    next 24 hours, and someone else hasn't already done it. :-)

    >When I follow the doc in installhtml, I get htmlwhich mostly works.
    >
    >Here's a sample:
    >
    >perl -w /ldata2/gnu/perl5.004/installhtml \
    > --podpath=lib:ext:pod:vms:win32:plan9:os2:h2pl:x2p:Porting:eg \
    > --podroot=/ldata2/gnu/perl5.004 \
    > --htmldir=/projects/sprs_lwv/HTML/perl \
    > --htmlroot=/projects/sprs_lwv/HTML/perl \
    > --recurse \
    > --splithead=pod/perlipc.pod \
    > --splititem=pod/perlfunc.pod \
    > --libpods=perlfunc:perlguts:perlvar:perlrun:perlop \
    > --verbose

     - Sarathy.
       gsar@engin.umich.edu

    p5p-msgid: 199706081749.NAA04552@aatma.engin.umich.edu

Subject: Re: make html --> unusable xref links
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml

    According to Jarkko Hietaniemi  <jhi@iki.fi>:
    :Jim Avera writes:
    : > If you set HTMLROOT=. in pod/Makefile, then cross-references
    : > say .//pod/... which does not work either.
    : > Setting HTMLROOT to an absolute path doesn't work either (the
    : > spurrious /pod/ is always there).
    : >
    : > What is the intent of the current setup (p54rc1)?

    When I follow the doc in installhtml, I get htmlwhich mostly works.

    Here's a sample:

    perl -w /ldata2/gnu/perl5.004/installhtml \
     --podpath=lib:ext:pod:vms:win32:plan9:os2:h2pl:x2p:Porting:eg \
     --podroot=/ldata2/gnu/perl5.004 \
     --htmldir=/projects/sprs_lwv/HTML/perl \
     --htmlroot=/projects/sprs_lwv/HTML/perl \
     --recurse \
     --splithead=pod/perlipc.pod \
     --splititem=pod/perlfunc.pod \
     --libpods=perlfunc:perlguts:perlvar:perlrun:perlop \
     --verbose

    p5p-msgid: 1997May16.191039.2033079@hmivax.humgen.upenn.edu

Subject: Re: make html --> unusable xref links
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml

    p5p-msgid: 87hgg2y1h4.fsf@perv.daft.com

Subject: make html --> unusable xref links
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml

    I don't understand how "make html" is intended to be used.

    By default (without editing the Makefile) the resulting .html files
    are useless -- they have broken cross-reference links.

    If you set HTMLROOT=. in pod/Makefile, then cross-references
    say .//pod/... which does not work either.
    Setting HTMLROOT to an absolute path doesn't work either (the
    spurrious /pod/ is always there).

    What is the intent of the current setup (p54rc1)?

    -Jim

    p5p-msgid: 9705161931.AA01075@membrane.hal.com

Subject: 5.004 POD stuff
From: "Darren/Torin/Who Ever..." <torin@daft.com>
Files: INSTALL pod/perldiag.pod installhtml
Msg-ID: 9705191839.AA28702@lemming.engeast

    (applied based on p5p patch as commit 1f8d2005982035a50557598064a5e9b1eef2b182)

 LIBRARY AND EXTENSIONS

Subject: sdbm can fail if a config.h exists in system directories
From: Tim Bunce <Tim.Bunce@ig.co.uk>
Files: ext/SDBM_File/sdbm/Makefile.PL

Subject: LWP and SIG __DIE__ traps not playing well together!
From: Gisle Aas <aas@bergen.sn.no>
Files: lib/AutoLoader.pm

Subject: Memory Consumption of autosplit_lib_modules/sv_gets (workaround)
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: lib/AutoSplit.pm

Subject: Comments of this Sys::Syslog patch
From: Jarkko Hietaniemi <jhi@iki.fi>
Files: lib/Sys/Syslog.pm

    Subject: clpm: 5.004 Sys::Syslog

    Russ Allbery  <rra@stanford.edu> writes:
    >Richard Dows <marius@randomc.com> writes:
    >
    >> I wanted to use Sys::Syslog, and so I tested it with a small script.  I
    >> get an error like so:
    >
    >> Undefined subroutine &Sys::Syslog::hostname called at
    >> /usr/local/lib/perl5/Sys/Syslog.pm line 92.  BEGIN failed--compilation
    >> aborted at stest line 3.
    >
    >This problem is fixed in (the just released) 5.004.

    However, 5.004 changed the behavior of Syslog.pm in an icky way.

    In 5.003, Syslog called Sys::Hostname to get the name of the
    host, and happily used that as the logging host.

    Now, Syslog calls Sys::Hostname to get the name of the host,
    strips off all the domain info, and uses that as the host:

    sub connect {
        unless ($host) {
     require Sys::Hostname;
     my($host_uniq) = Sys::Hostname::hostname();
     ($host) = $host_uniq =~ /([\w\-]+)/;
        }

       ....etc.....

    Was this intentional? It screws up systems which use an FQDN as their
    hostname and don't list the stripped-down version in their /etc/hosts
    file, because inet_aton fails on the stripped-down name.

    Was /([\w\-\.]+)/ what was meant?

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
             Alan Schwartz           | Disclaimer: I represent no one
                                     |
    alansz@cogsci.berkeley.edu       | "Life is what happens to you while
    UC Berkeley                      |  you're busy making other plans"
    Cognitive Psychology             |          - J. Lennon
    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

    p5p-msgid: 199705231621.TAA16790@alpha.hut.fi

Subject: Patch to CPAN.pm (perl5.004) for ncftp
From: "Richard L. Maus <rmaus@monmouth.com>
Files: lib/CPAN.pm
Msg-ID: 337FBAC8.167EB0E7@monmouth.com

    (applied based on p5p patch as commit 1f8d2005982035a50557598064a5e9b1eef2b182)

Subject: [PATCH] Harness.pm bug w/perl5.004 & VMS
From: Dan Sugalski <sugalsd@lbcc.cc.or.us>
Files: lib/Test/Harness.pm
Msg-ID: 3.0.1.32.19970530102300.008a2730@stargate.lbcc.cc.or.us

    (applied based on p5p patch as commit 2d8ca5da0888ace50c79900af6ef82761bea90b2)

Subject: more Fcntl constants [PATCH]
From: Jarkko Hietaniemi <jhi@iki.fi>
Files: ext/Fcntl/Fcntl.pm ext/Fcntl/Fcntl.xs

 PORTABILITY

Subject: win32: additional default libraries
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: lib/ExtUtils/MM_Win32.pm
Msg-ID: 199705291332.JAA21560@aatma.engin.umich.edu

    (full description at 14ba8c9ed9cfdc22434f89b374aaf17cc48fd4a0)
    (base was difficult to find)

Subject: clean up perlocal.pod output on VMS
From: Peter Prymmer <pvhp@forte.com>
Files: lib/ExtUtils/MM_VMS.pm

Subject: Re: Term::ReadKey on Win32: set console
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: lib/Term/ReadLine.pm

Subject: Pod::Text nit for Win32
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: lib/Pod/Text.pm

Subject: MakeMaker stumbles on Win32 UNC paths
From: Warren Jones <wjones@TC.FLUKE.COM>
Files: lib/ExtUtils/MM_Win32.pm

Subject: build problem on SGI R10000 PowerChallenge (IRIX 6.2) lseek proto
From: Jarkko Hietaniemi <jhi@iki.fi>
Files: doio.c

Subject: Perl 5.004 + Linux 2.0.30 & semctl()
From: Andy Dougherty <doughera@fractal.phys.lafayette.edu>
Files: doio.c

Subject: lib/io_udp.t fails on VMS
From: Jonathan Hudson <Jonathan.Hudson@jrhudson.demon.co.uk>
Files: pp_sys.c
Msg-ID: XFMail.970522181042.Jonathan.Hudson@jrhudson.demon.co.uk

    (applied based on p5p patch as commit 490ab354c465618bcdee84ecc1d256c265518f0a)

Subject: (NEXT|OPEN)STEP hints
From: Gerd Knops <gerti@BITart.com>
Files: hints/next_3.sh hints/next_4.sh

Subject: win32: user defined shell
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: pod/perlrun.pod win32/win32.c
Msg-ID: 199705291339.JAA21682@aatma.engin.umich.edu

    (applied based on p5p patch as commit 174c211a66516a872d3a421681076bee9a56fa2b)

Subject: win32: Configure cf_email
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: win32/Makefile win32/config.bc win32/config.vc win32/config_sh.PL win32/makefile.mk
Msg-ID: 199705301335.JAA05079@aatma.engin.umich.edu

    (applied based on p5p patch as commit d484a8290f98952e0e3a67e0aae9aa08c631f5c2)

Subject: README.win32 nits
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: README.win32

Subject: SVR4 hints for DDE SMES Supermax Enterprise Server
From: Jarkko Hietaniemi <jhi@iki.fi>
Files: hints/svr4.sh

Subject: porting.help
From: Tim Bunce <Tim.Bunce@ig.co.uk>
Files: Porting/pumpkin.pod Porting/preprel

Subject: "Major 5.004 Win32 update (Borland win32 support, and other patches)",
 "($a,undef,$b) = qw(a b c) and ties delaying DESTROY fixes"
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: MANIFEST pod/perlguts.pod win32/include/sys/socket.h EXTERN.h opcode.h perl.h regcomp.h ext/Fcntl/Fcntl.pm ext/SDBM_File/Makefile.PL lib/ExtUtils/Install.pm lib/ExtUtils/MM_Unix.pm lib/ExtUtils/MM_Win32.pm lib/ExtUtils/MakeMaker.pm lib/ExtUtils/Mksymlists.pm lib/File/DosGlob.pm t/op/mkdir.t t/op/stat.t win32/win32.h win32/win32io.h win32/win32iop.h README.win32 doio.c gv.c mg.c op.c perlio.c pp.c pp_ctl.c pp_hot.c pp_sys.c util.c win32/Makefile win32/config.bc win32/config.vc win32/config_H.bc win32/config_H.vc win32/makedef.pl win32/makefile.mk win32/makeperldef.pl win32/perlglob.c win32/perllib.c win32/win32.c win32/win32io.c win32/win32sck.c

Subject: Re: Maintenance release (remove PERL_DUMMY_SIZE)
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: opcode.h perl.h regcomp.h win32/win32.h gv.c

Subject: ENV leaks on win32 (was Re: Comments on ENV patch sought)
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: win32/win32.h win32/win32io.h win32/win32iop.h global.sym mg.c perl.c t/op/magic.t util.c win32/makedef.pl win32/win32.c win32/win32io.c

Subject: win32: ExtUtils::Liblist support
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: lib/ExtUtils/Liblist.pm win32/Makefile win32/config.bc win32/makefile.mk

Subject: Re: borland C++Perl embedding failures re __declspec()
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: win32/win32.c

 TESTS

Subject: Tests depend on locale
From: "Jan D." <jan.djarv@mbox200.swipnet.se>
Files: t/lib/safe2.t t/op/mkdir.t
Msg-ID: 199705191230.PAA21070@alpha.hut.fi,
199705191127.NAA08148@ostrich.gaia.swipnet.se

    (applied based on p5p patch as commit 3458556dd685b1767b760a72bd2e9007b5c4575e)

Subject: More simple regexp tests and test docs
From: Hans Mulder <hansm@euronet.nl>
Files: t/op/re_tests t/op/regexp.t

Subject: Re: Using undef to ignore values returned from split
From: Hugo van der Sanden <hv@crypt.compulink.co.uk>
Files: t/op/split.t

 UTILITIES

Subject: bad test of -A flag in h2xs
From: "Jeffrey S. Haemer" <jsh@woodcock.boulder.qms.com>
Files: utils/h2xs.PL

Subject: h2xs missing from utils/Makefile
From: Hans Mulder <hansm@euronet.nl>
Files: utils/Makefile

Subject: final newline missing in MANIFEST generated by h2xs
From: Hans Mulder <hansm@euronet.nl>
Files: utils/h2xs.PL

Tests depend on locale

This is (sort of) documented in INSTALL.  But you are right,
the tests should force the LC_ALL to be 'C'.  Note: LANG is
not enough, and neither is POSIX as readily available as C.
Here are the patches:

p5p-msgid: 199705191230.PAA21070@alpha.hut.fi
Signed-off-by: Jarkko Hietaniemi <jhi@iki.fi>

PATCH: bug in perlbug w.r.t. environment variables

Here is patch for the problem, this adds sorting all of the environment
(I see little point in sorting just some).

p5p-msgid: 199705191857.VAA09154@alpha.hut.fi
Signed-off-by: Jarkko Hietaniemi <jhi@iki.fi>

win32: Configure cf_email

Subject: [PATCH] win32: cf_email (was Re: Win32 embedding w/ 5.004)

On Fri, 30 May 1997 11:01:57 +0800, "Gary Ng (Systek)" wrote:
>Nick and Sarathy contribute much more that me. BTW, anyone
>notice that perl -V on win32 still show 'garyng' no matter who build it
>:-)
>Can that be removed ?

Actually perl -V doesn't show that for me, but perlbug does.
Here's a patch.

p5p-msgid: 199705301335.JAA05079@aatma.engin.umich.edu

h2xs missing from utils/Makefile

win32: user defined shell

This patch replaces the patch in win32.3 in the gnat collection.

The reasons for reworking that patch should be evident from
reading the patch below.

p5p-msgid: 199705291339.JAA21682@aatma.engin.umich.edu

Re: Using undef to ignore values returned from split

lib/io_udp.t fails on VMS

perl 5.004 built without error or warning on VMS AXP/DECC with DECCRTL
(UCX) sockets (no sockshr library). However it fails the
lib/io_udp.t test for the following reasons:

1. The 'fromlen' parameter in pp_sysread *must* be sizeof(struct
   sockaddr) or the DECCRTL fails with an invalid buffer size error.

2. The DECCRTL/UCX getpeerhost() function returns defined and a blank
   'sockaddr' for udp hosts. A similar fix to that in vms/sockadapt.h
   (for sockshr) is required for DECCRTL in pp_sys.c

The following diff (unix, sorry VMS folks) patches pp_sys.c so that
the udp test is successful using UCX.

p5p-msgid: XFMail.970522181042.Jonathan.Hudson@jrhudson.demon.co.uk

More simple regexp tests and test docs

win32: additional default libraries

I found the default libs list is still incomplete (incomplete
enough for Tk to fail to build).

This patch adds the additional default libraries to MM_Win32.pm.
Note LDLOADLIBS can be overridden from Makefile.PL (although
Tk/win32 seems to want to set it directly in its Makefile,
rather than via an attribute list, and the direct setting gets
overridden by the default because the default comes later in
the makefile).

The patch is against the jumbo patch that nobody seems to like.
It is *my* new baseline, sorry.

 - Sarathy.
   gsar@engin.umich.edu

p5p-msgid: 199705291332.JAA21560@aatma.engin.umich.edu

[dummy merge]

This merge exists so that the p5p version of the patch and the applied
version are both in the history

Compiling perl5.004 on NEWS-OS 4.x

Here (attached below) is a patch for compiling perl5 on NEWS-OS 4.x. It
contains a new hints file for NEWS-OS 4.x and some modification to
Configure.  I've tested on perl5.003, perl5.003_99 and perl5.004.

Background: Current release of NEWS-OS is version 6.1.x and it is
SystemV variant. However, NEWS-OS 4.x is 4.3BSD-variant and commonly
used in Japan. So, I named 'newsos' for newer release, and 'newsos4'
for older release. Unfortunately, NEWS-OS 4.x has no uname(1).

p5p-msgid: 19970521132814F.matusita@ics.es.osaka-u.ac.jp

op/groups test fails on Linux (groups in /bin)

(this is the same change as commit 7b7ef14c26e3283cb33eb794bdf774867119ade0, but as applied)

op/groups test fails on Linux (groups in /bin)

The test op/groups checks for groups in /usr/bin and /usr/ucb.
This fails on some Linux distributions that has groups in /bin.

A better test would be to just run groups (take whatever is in the
path) and see if it outputs a list that includes the current
group.  Possibly you could prepend /bin:/usr/bin:/usr/ucb to the
current path.  Something like this.

p5p-msgid: 199705191120.NAA08130@ostrich.gaia.swipnet.se

INSTALL-1.18

This patch fixes two problems in the INSTALL file in 5.004.  This fix is
appropriate for 5.004_01.

First, the INSTALL file erroneously claims you can set all the install*
variables from the Configure command line.  You can't.  That's awaiting my
-Dinstallprefix patch, which is so far down on the ToDo list that it may
never get done.

Second, I misspelled 'override'.  I had two 'v's and one 'r'. :-)

p5p-msgid: Pine.SOL.3.95q.970529142739.662D-100000@fractal.lafayette.edu

SVR4 hints for DDE SMES Supermax Enterprise Server

5.004 POD stuff

Caught a small typo in perldiag.pod; patch below.

p5p-msgid: 9705191839.AA28702@lemming.engeast
Signed-off-by: "Paul D. Smith" <psmith@BayNetworks.COM>
Signed-off-by: Gurusamy Sarathy <gsar@engin.umich.edu>
Signed-off-by: Jarkko Hietaniemi <jhi@iki.fi>
Signed-off-by: Michael R Cook <mcook@cognex.com>
Signed-off-by: Jim Avera <avera@hal.com>
Signed-off-by: Larry W. Virden <lvirden@cas.org>