Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[Michael G Schwern]

On Tue, Jul 26, 2005 at 12:37:03AM -0400, John E. Malmberg wrote:
> The zlib module would not build.  I had to change the makefile.pl to fix 
> that.
> 
> What was needed is a space between the "@" and a macro which expanded to 
> MCR imagename.  With out that space, MMK interprets the @ to run 
> MCR.COM.  I do not know if the makemaker code should have fixed this, or 
> if it is a bug in the makefile.pl.

Its a bug in the Makefile.PL.  That section is all raw make code tacked onto
the end of the generated Makefile.


> --- ext/compress/zlib/makefile.pl_blead   Mon Jul 25 21:33:47 2005
> +++ ext/compress/zlib/makefile.pl Mon Jul 25 21:32:52 2005

If possible, try to preserve case on filenames.  Otherwise the pumpkings 
will have to hand twiddle the patch files to make them apply.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[Abe Timmerman]

Op een mooie zomerdag (Tuesday 26 July 2005 06:37),schreef  John E. Malmberg:
> When I pulled down a new copy today, for some reason the vms/vmsish.h
> was missing some of the required const prototypes in order to compile
> vms.c, so I am confused as to how it seemed to be building yesterday.
>
> I suppose I should change the subject as it is against a different days
> blead, but I have no idea where the number 25210 came from.

25210 is the changenumber assigned by the version control system. In the rsync 
archive the changenumber is put in the file ".patch".

[snip]

> My build just died because it can not figure out how to create
> pod/perlcygwin.pod.  As near as I can tell, that file was supposed to be
> in the distribution, but rsync does not report it as available for
> download, and it is not in the MANIFEST. file.

Unlike pod/perlvms.pod (which is copied from vms/perlvms.pod); all the other 
pod/perl.pod files are generated (copied) from README. during the 
build process

HTH +
Good luck,

Abe
-- 
"Crashes Perl (or Used To)" is not a really useful classifying 
criterion, it's about as useful as "the number of characters in 
the test is divisible by 73".
   -- Jarkko Hietaniemi on p5p @ 2001-10-30

Re: [PATCH lib/Pod/Perldoc.pm] search perlvar with perldoc -a

[Michael G Schwern]

On Mon, Jul 25, 2005 at 05:58:06PM -0400, Ivan Tubert-Brohman wrote:
> The effect of this patch is that you can now use
> 
>   perldoc -a '$_'
> 
> to look for $_ in perlvar.
> 
> I'm not entirely happy with the letter I chose ('a'). Obviously -v or -V 
> would be easier to remember, but they were both taken, and they are 
> frequently associated with verbosity and version anyway. I chose 'a' 
> because its the next letter in vAriable, but if you can come up with 
> something better I'm all ears. I also considered making -f look at both 
> perlfunc and perlvar, but that is questionable because, of course, 
> variables are not functions. ;-)

--var?

This cracks open --foo style configs in perldoc, but if its getting that
hard to wedge in new features maybe its time they did so and recovered some
of the less used single letter options, like -w -n -d -o -M and -X, by
moving them to --foo style.

perldoc is currently using over half the alphabet as switches.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml

[PATCH lib/Pod/Perldoc.pm] search perlvar with perldoc -a

[Ivan Tubert-Brohman]

Hi,

I sent this to Sean Burke a few days ago. I haven't got any reply, but 
later I noticed that perlhack suggests sending a copy to p5p, so here it is.


-

I've always wanted to be able to use perldoc to quickly look up a Perl 
predefined variable in perlvar, the same way I can now look up a 
function in perlfunc with perldoc -f. Today I decided to do something 
about it, so I modified my perldoc to do precisely that. I'm attaching 
the patch relative to the Pod-Perldoc-3.14 distribution, in case you are 
interested in adding it to the official version.


The effect of this patch is that you can now use

  perldoc -a '$_'

to look for $_ in perlvar.

I'm not entirely happy with the letter I chose ('a'). Obviously -v or -V 
would be easier to remember, but they were both taken, and they are 
frequently associated with verbosity and version anyway. I chose 'a' 
because its the next letter in vAriable, but if you can come up with 
something better I'm all ears. I also considered making -f look at both 
perlfunc and perlvar, but that is questionable because, of course, 
variables are not functions. ;-)


Cheers,
Ivan ([EMAIL PROTECTED])
diff -ru Pod-Perldoc-3.14/lib/Pod/Perldoc.pm 
Pod-Perldoc-3.14.with-perlvar/lib/Pod/Perldoc.pm
--- Pod-Perldoc-3.14/lib/Pod/Perldoc.pm 2004-11-30 17:27:31.0 -0500
+++ Pod-Perldoc-3.14.with-perlvar/lib/Pod/Perldoc.pm2005-07-20 
20:24:59.779576256 -0400
@@ -62,13 +62,14 @@
 #
 # Option accessors...
 
-foreach my $subname (map "opt_$_", split '', q{mhlvriFfXqnTdU}) {
+foreach my $subname (map "opt_$_", split '', q{amhlvriFfXqnTdU}) {
   no strict 'refs';
   *$subname = do{ use strict 'refs';  sub () { shift->_elem($subname, @_) } };
 }
 
 # And these are so that GetOptsOO knows they take options:
 sub opt_f_with { shift->_elem('opt_f', @_) }
+sub opt_a_with { shift->_elem('opt_a', @_) }
 sub opt_q_with { shift->_elem('opt_q', @_) }
 sub opt_d_with { shift->_elem('opt_d', @_) }
 
@@ -238,6 +239,7 @@
   die <{'pages'} = [EMAIL PROTECTED];
 if($self->opt_f) { @pages = ("perlfunc")   }
+elsif( $self->opt_a) { @pages = ("perlvar")}
 elsif( $self->opt_q) { @pages = ("perlfaq1" .. "perlfaq9") }
 else { @pages = @{$self->{'args'}};
# @pages = __FILE__
@@ -755,9 +763,11 @@
 
 $self->search_perlfunc($found_things, [EMAIL PROTECTED])  if  $self->opt_f;
 
+$self->search_perlvar($found_things, [EMAIL PROTECTED])   if  $self->opt_a;
+
 $self->search_perlfaqs($found_things, [EMAIL PROTECTED])  if  $self->opt_q;
 
-if( ! $self->opt_f and ! $self->opt_q ) {
+if( ! $self->opt_f and ! $self->opt_q and ! $self->opt_a ) {
 DEBUG > 4 and print "That's a non-dynamic pod search.\n";
 } elsif ( @dynamic_pod ) {
 $self->aside("Hm, I found some Pod from that search!\n");
@@ -766,7 +776,7 @@
 push @{ $self->{'temp_file_list'} }, $buffer;
  # I.e., it MIGHT be deleted at the end.
 
-   my $in_list = $self->opt_f;
+   my $in_list = $self->opt_f || $self->opt_a;
 
 print $buffd "=over 8\n\n" if $in_list;
 print $buffd @dynamic_pod  or die "Can't print $buffer: $!";
@@ -857,6 +867,64 @@
 
 #..
 
+sub search_perlvar {
+my($self, $found_things, $pod) = @_;
+
+DEBUG > 2 and print "Search: @$found_things\n";
+
+my $perlvar = shift @$found_things;
+open(PVAR, "<", $perlvar)   # "Funk is its own reward"
+or die("Can't open $perlvar $!");
+
+my $search_re = $self->opt_a;
+
+# in case they give us an actual control character
+$search_re =~ s/([[:cntrl:]])/'^'.chr(ord($1)+64)/eg;
+
+DEBUG > 2 and
+ print "Going to perlvar-scan for $search_re in $perlvar\n";
+
+$search_re = qr/^=item\s+\Q$search_re\E/;
+
+# Skip introduction
+local $_;
+while () {
+last if /^=over 8/;
+}
+
+# Look for our variable
+my $found = 0;
+my $inlist = 0;
+while () {  # "The Mothership Connection is here!"
+if ( m/$search_re/ )  {
+$found = 1;
+}
+elsif (/^=item/) {
+last if $found > 1 and not $inlist;
+}
+next unless $found;
+if (/^=over/) {
+++$inlist;
+}
+elsif (/^=back/) {
+--$inlist;
+}
+push @$pod, $_;
+++$found if /^\w/;# found descriptive text
+}
+if ([EMAIL PROTECTED]) {
+die sprintf
+  "No documentation for perl variable `%s' found\n",
+  $self->opt_a
+;
+}
+close PVARor die "Can't open $perlvar: $!";
+
+return;
+}
+
+#..
+
 sub search_perlfaqs {
 my( $self, $found_things, $pod) = @_;
 
diff -ru Pod-Perldoc-3.14/lib/perldoc.pod 
Pod-Perldoc-3.14.with-perlvar/lib/perldoc.pod
--- 

Re: File::Path's rmtree - CAN-2005-0448

[Michael G Schwern]

On Mon, Jul 25, 2005 at 08:07:11AM -0700, Gisle Aas wrote:
> This is how our File::Path now differs from the one found at
> rsync://ftp.linux.activestate.com/perl-5.8.x:

That's a whole lotta code change.  Is any of it whitespace?  Can it be
reduced using -b?

Any chance we could see this as a set of patches pulled from your repo?


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
ROCKS FALL! EVERYONE DIES!
http://www.somethingpositive.net/sp05032002.shtml

Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts

[Michael G Schwern]

On Mon, Jul 25, 2005 at 11:21:24AM +0200, H.Merijn Brand wrote:
> > On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote:
> > > Personally, I don't like the new documentation in this patch.  It seems to
> > > put the focus more on correcting the issue about encryption, rather than
> > > actually documenting what crypt() does.
> 
> I have applied the combo of these two as change #25220
> In the future I'd prefer a *new* patch that would overrule the first (unless
> that was already applied and acknowledged to the list). Now I had to apply
> the first before applying the second.

Ooops, I thought the second one was a combo.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Ahh email, my old friend.  Do you know that revenge is a dish that is best 
served cold?  And it is very cold on the Internet!

Re: [perl #36235] perl + gcc-4.0.0 + solaris + gnu binutils

[Andy Dougherty]

On Thu, 10 Jun 2005, Niki W. Waibel wrote:

> # New Ticket Created by  "Niki W. Waibel" 
> # Please include the string:  [perl #36235]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/rt3/Ticket/Display.html?id=36235 >
> 
> 
> perl on solaris using gcc-3.X and gnu binutils correctly adds -Wl,-E to
> to LDFLAGS. it seems that the detection of the gnu binutils is somehow
> broken if gcc-4.X is used.

The detection is done in hints/solaris_2.sh.  It's quite possible that the 
output of gcc has changed such that the hints file doesn't pick it up 
correctly anymore.

Could you please create a trivial "Hello world" C program and then compile 
it with

gcc-3.X -v -o hello hello.c > gcc3.out 2>&1
gcc-3.X -Wl,-V -o hello hello.c > gcc3-Wl.out 2>&1
gcc-4.0 -v -o hello hello.c > gcc4.out 2>&1
gcc-4.0 -Wl,-V -o hello hello.c > gcc4-Wl.out 2>&1

(adjusting the exact gcc names as needed.)

and send me the various *.out files?  Then perhaps I can see
why the hints/solaris_2.sh file is failing.

-- 
Andy Dougherty  [EMAIL PROTECTED]

Re: [perl-5.8.7] Perl regression tests fail when lib directory is present

[Gerrit P. Haase]

Christopher Faylor wrote:

On Fri, Jul 22, 2005 at 03:16:29PM -0500, Scott Bolte wrote:


On Thu, 21 Jul 2005 00:14:51 -0700, Michael G Schwern wrote:



Its gotta be something about _default_inc().  Nothing looks wrong from
here.  My only guess is that local $ENV{PERL5LIB} is ineffective.  That
would account for the alternation.


It's not just the local scoping. There is something
seriously unexpected with environment variables, perl
and cygwin.

- th4.pl
#!/usr/bin/perl
use strict;
use warnings;
		 
		$ENV{SHOULD_NEVER_BE_SEEN} = "hello world";

delete($ENV{SHOULD_NEVER_BE_SEEN});
system("printenv | grep SHOULD_NEVER_BE_SEEN");

On UNIX systems that script properly prints nothing. Not so
on my cygwin (on top of XP) system:

cygwin% perl ~/th4.pl
SHOULD_NEVER_BE_SEEN=hello world

It seems to imply that the results of unsetenv(3) are not
persistent across an exec(2).



or that perl isn't using unsetenv, since AFAICT, unsetenv() is operating
as it should for both cygwin and non-cygwin processes.

This was a standard problem way way back when I was maintaining my own
version of perl for cygwin (since cygwin didn't include perl).  There was
special code in perl to deal with cygwin's environment, IIRC.  Maybe it's
broken in 5.8.7.

cgf


Indeed, I see no unsetenv() in the perl sources.

Since it seems that the problem is independent of TH the problem should
be located in perl itself.  I'll try with a recent devel version to see
if it fails here too.  Scott, have you tried te above script with other
(older) versions of Cygwin perl too?  Since TH works with perl-5.8.6 I
suspect some of the changes integrated into maint perl to be problematic
for Cygwin, however it may also be an older bug in Cygwin perl.


Gerrit

Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!

[Shiping Zhang]

> From [EMAIL PROTECTED] Fri Jul 22 18:48:32 2005
> Subject: Re: [perl #36616] bug or feature? foreach (sort @array) 
> {y/a-z/A-Z/;} # @array modified!
> From: "Scott R. Godin via RT" <[EMAIL PROTECTED]>
> X-RT-Loop-Prevention: perl
> RT-Ticket: perl #36616
> Managed-by: RT 3.0.11 (http://www.bestpractical.com/rt/)
> RT-Originator: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Date: Fri, 22 Jul 2005 15:46:36 -0700
> 
>  > By "not documented', I was refering to what is supposed to be returned by
>  > sort. To a Perl programer, should what's returned by sort be considered a
>  > 'true' copy of a original list (albeit sorted) which can be worked on 
> without
>  > affecting the original list under any circumstances?  As far as I see it, 
> in
>  > the code of 'foreach (sort @array){}', foreach is stepping through a sorted
>  > copy returned by sort at the time sort has already finished and @array
>  > forgotten. So I wouldn't expect @array to be changed.  The current 
> behavior is
>  > a bad behavior to say the least.  I would be very surprised if Larry would
>  > design the code to behave in such a way. ;-)
> 
> I'm not so sure about that..
> 
> sort @a is just @a sorted. if I wanted a sorted copy of @a I'd do it 
> implicitly:
> @b = sort @a , as in foreach (my @b = sort @a) {}. As someone else pointed 
> out, 
> sort is similar to grep in this respect.
> 
> When I first looked at this question, I thoroughly discounted sort as being 
> 'part of the problem', and looked straight to the aliasing behaviour of 
> foreach, 
> since you're merely receiving @a back, just sorted first.

But @a itself is not sorted, so you can't say you are receiving @a back.

> if I wanted a copy of @a I'd ask for it. Perhaps this needs to be documented 
> better in the above three perldocs but I don't see it as a bug whatsoever. It 
> (foreach) is doing exactly what I'd have expected of it, myself, 
> sorted/grepped 
> or not...

The question here is not about the behavior of foreach, but that of
sort and its documentation.  The "alias nature" of foreach and grep
is documentated and such nature makes some sense: foreach lets you
step through each element and grep lets you target certain elements
of the list, so it's not completely out of logic to return aliases
to those elements so you can easily make change to each element or
the targeted elements.
 
Here are some words from http://perldoc.perl.org/functions/grep.html:
Similarly, grep returns aliases into the original list, much as a for
loop's index variable aliases the list elements. That is, modifying
an element of a list returned by grep (for example, in a foreach , map
or another grep) actually modifies the element in the original list.
But no such words about sort. Had I seen such words about sort, I wouldn't
have brought it up (though I would still had wondered why).


This communication is for use by the intended recipient and contains 
information that may be privileged, confidential or copyrighted under
applicable law.  If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited.  Please notify the sender
by return e-mail and delete this e-mail from your system.  Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer.  This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.

 Francais Deutsch Italiano  Espanol  Portugues  Japanese  Chinese  Korean

http://www.DuPont.com/corp/email_disclaimer.html

Re: [perl #36616] bug or feature? foreach (sort @array) {y/a-z/A-Z/;} # @array modified!

[Shiping Zhang]

I agree.

> From [EMAIL PROTECTED] Mon Jul 25 08:08:53 2005
> Subject: Re: [perl #36616] bug or feature? foreach (sort @array) 
> {y/a-z/A-Z/;} # @array modified!
> From: "Michael G Schwern via RT" <[EMAIL PROTECTED]>
> X-RT-Loop-Prevention: perl
> RT-Ticket: perl #36616
> Managed-by: RT 3.0.11 (http://www.bestpractical.com/rt/)
> RT-Originator: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> X-RT-Original-Encoding: utf-8
> Date: Sat, 23 Jul 2005 19:59:43 -0700
> MIME-Version: 1.0
> 
> This is a multi-part message in MIME format...
> 
> =_1122173983-30846-1
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 7bit
> 
> So it sounds like the resolution for this bug is to document that sort
> uses aliases like grep does.  I've stolen the wording from grep.
> 
> -- 
> Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
> Reality is that which, when you stop believing in it, doesn't go away.
>   -- Phillip K. Dick
> 
> 
> =_1122173983-30846-1
> Content-Type: text/plain; charset="us-ascii"; name="sort.pod.patch"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline; filename="sort.pod.patch"
> 
> --- pod/perlfunc.pod  2005/07/24 02:57:16 1.2
> +++ pod/perlfunc.pod  2005/07/24 02:58:42
> @@ -4926,6 +4926,12 @@
>  When C is in effect, C sorts LIST according to the
>  current collation locale.  See L.
>  
> +sort returns aliases into the original list, much as a for loop's
> +index variable aliases the list elements.  That is, modifying an
> +element of a list returned by sort (for example, in a "foreach", "map"
> +or "grep") actually modifies the element in the original list.  This
> +is usually something to be avoided when writing clear code.
> +
>  Perl 5.6 and earlier used a quicksort algorithm to implement sort.
>  That algorithm was not stable, and I go quadratic.  (A I sort
>  preserves the input order of elements that compare equal.  Although
> 
> =_1122173983-30846-1--
> 


This communication is for use by the intended recipient and contains 
information that may be privileged, confidential or copyrighted under
applicable law.  If you are not the intended recipient, you are hereby
formally notified that any use, copying or distribution of this e-mail,
in whole or in part, is strictly prohibited.  Please notify the sender
by return e-mail and delete this e-mail from your system.  Unless
explicitly and conspicuously designated as "E-Contract Intended",
this e-mail does not constitute a contract offer, a contract amendment,
or an acceptance of a contract offer.  This e-mail does not constitute
a consent to the use of sender's contact information for direct marketing
purposes or for transfers of data to third parties.

 Francais Deutsch Italiano  Espanol  Portugues  Japanese  Chinese  Korean

http://www.DuPont.com/corp/email_disclaimer.html

RE: [PATCH] Re: [PATCH] support POSIX SA_SIGINFO

[Green, Paul]

My weekly build of bleedperl failed last night:

mg.c: In function `Perl_sighandler':
mg.c:2715: structure has no member named `si_errno'

I tracked it down to the sa_siginfo changes.

Stratus VOS implements the 1996 revision of the POSIX standard.  That
version defines the minimum siginfo_t type to have the members si_code,
si_signo, and si_value.  The 2001 revision of the POSIX standard adds
the si_errno, si_pid, si_uid, si_addr, si_status, and si_band members.

As far as I can tell, the si_errno value is never used in perl.  So I
hope that I'm not offending anyone by submitting the attached patch that
moves it under the #if 0 clause as well.

Thanks
PG
--
Paul Green, Senior Technical Consultant, Stratus Technologies.
Voice: +1 978-461-7557; FAX: +1 978-461-3610; AIM: PaulGreen

  

> -Original Message-
> From: Jarkko Hietaniemi [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 21, 2005 11:33 AM
> To: Dominic Dunlop
> Cc: Nicholas Clark; [EMAIL PROTECTED]; Steve Peters; Perl 5 Porters
> Subject: [PATCH] Re: [PATCH] support POSIX SA_SIGINFO
> 
> > I agree. Mac OS X tells me nothing apart from what's in signal.h,  
> 
> man siginfo in Solaris and man sigaction in AIX and Tru64 are quite
> helpful.  But I think for the time being the attached patch will have
> to do: only signo, code, errno are decoded (seems the be the smallest
> supported set from my smaple), and the test is changed to 
> test just for
> the signal value itself -- I can't see why anyone would bother
> implementing even a little bit of SA_SIGINFO and fail to supply
> the signal value -- but I have been known to be too optimistic.
> If even that fails, the whole test needs to be excised.
> 
> Perl cannot help systems that aren't POSIX, whether they claim it or
> not, on purpose or not.
> 
> 
> 
> 
> 


mg.c.diff
Description: mg.c.diff

Perl5 Bug Summary

[Robert Spier]

Perl5 Bug Summary

http://rt.perl.org/rt3/NoAuth/perl5/Overview.html
Generated at Mon Jul 25 12:58:34 2005 GMT
---

  * Total Issues
  * New Issues
  * Overview of Open Issues
  * Ticket Status By Version
  * Requestors with most open tickets

---

Total Issues

Open Tickets: 1467

---

New Issues

New issues that have not been responded to yet

1 - 2 weeks old
36539 Edge cases in "find_perl" algorithms
36516 attributes.pm documentation is recursive and incomplete
36513 Pod::Html exports two undocumented functions
2 - 3 weeks old
3 - 4 weeks old
36448 configuring ranlib for perl on osx with xcode 2.1
36430 Sort within a sort does not set $a, $b
4 - 5 weeks old
36347 Object destruction incomplete
5 - 6 weeks old
36333 sort CONSTANT exhibits weird behavior
36291 incorrect $! from open ">&nr" with too many open files
6 - 7 weeks old
36248 print does not respect "use encoding 'utf8'"
36235 perl + gcc-4.0.0 + solaris + gnu binutils
36229 Bizarre copy of IO
7 - 8 weeks old
36094 Wrong line number for FILEHANDLE reported by Xref (Xref.pm V1.01)
36079 use of `sexed' quotes gnot Unicode
36078 Newz() used gratuitously
36076 sv_upgrade and structure binary compatibility
36075 malloc_size/malloc_good_size
36070 Not OK: perl v5.8.7 on darwin-thread-multi-2level 8.1.0 (UNINSTALLED)
36051 LVALUE magic should know how to assign to globs
36049 Merge all the arenas
36046 Special var @- becomes arbitrarily large
8 - 9 weeks old
9 - 10 weeks old
35949 'use locale' does not enable number formatting locale
35865 tied hash bug (still present in 5.8.7-to-be), Test::More attached
10 - 11 weeks old
35427 reset coredumps pre 5.8.0
35406 Wishlist about Sys::Syslog.
11 - 12 weeks old
35180 inconsistency between PerlIO::get_layers and open/binmode
12 - 13 weeks old
35132 METABUG - AIX build issues
13 - 14 weeks old
35050 Installation Problem Perl 5.8.6 on AIX 5.2
14 - 15 weeks old
34981 binding STDIN to scalar hides fd 0 forever
15 - 16 weeks old
34905 Encode::encode and destruction of the argument
16 - 17 weeks old
34599 Perl program uses tied filehandle crashes in Komodo 3.1 debugger
17 - 18 weeks old
18 - 19 weeks old
34497 hp2h unable to parse macros which have variable initialization
34496 h2ph is unable to parse do { ... } while (0) constructs in macros
34495 h2ph is unable to catenate constant strings in macros
34489 perl5db.pl noTTY=1 AutoTrace=1 cause problems
19 - 20 weeks old
20 - 21 weeks old
34349 SIGSEGV in S_regmatch
34342 @_ leaks under threads
34339 "perldoc lib" doesn't describe actual behavior of "use lib"
34310 constants in Regex Variable index
34297 utf8 overload stringify bug (utf8 caching maybe)
34296 Bug with sv_rvweaken on tied variables

---

Overview of Open Issues

Operating System   Severity  Type Perl Version
aix   29   fatal  2  Bug  2   5.000  1
All   19   High 137  compiler 1   5.004  1
bsdos  4   low  742  configure3   5.004_00   1
cygwin16   medium   354  core   579   5.004_01   1
cygwin_nt  1   none   9  docs21   5.004_02   1
darwin23   Normal 4  HasTest  2   5.004_03   1
dec_osf   14   Wishlist  23  install 43   5.004_04   1
dos1 library186   5.004_05   1
freebsd   53 notabug 65   5.005  1
generic   38 notok2   5.005_01   1
HPUX  21 Patch3   5.005_02   1
irix   9 regex   11   5.005_03  34
Linux534 sendToCPAN   2   5.005_04   3
machten1 Todo 1   5.6.0132
mswin32   86 unknown314   5.6.1174
netbsd 8 utilities   23   5.6.2  8
openbsd3  5.7.0 23
os26  5.7.1 13
powerux1  5.7.2 31
qnx1  5.8.0232
riscos 1  5.8.1 58
sco4  5.8.2 52
Solaris  135  5.8.3 75
sunos  2  5.8.4 72
svr4   3  5.8.5 40
svr5   1

File::Path's rmtree - CAN-2005-0448

[Gisle Aas]

This is mostly an FYI.  The patch below might not yet be suitable for
blead as the MacOS and VMS special cases found in the old rmtree are
not taken care of.

For ActivePerl we have updated File::Path's rmtree based on Debian's
patch  with these
enhancements:

   - restore '$force_writeable' behaviour (for Windows)
   - make rmtree able to delete directories lacking 'x' permissions
 (the old rmtree could do this).
   - avoid loading of Errno (so that miniperl can use the function)
   - some stylistic and typo fixes

This is how our File::Path now differs from the one found at
rsync://ftp.linux.activestate.com/perl-5.8.x:

--- lib/File/Path.pm2005-05-05 09:16:20.0 -0700
+++ lib/File/Path.pm2005-07-15 13:33:15.0 -0700
@@ -33,7 +33,7 @@
 =item *
 
 the numeric mode to use when creating the directories
-(defaults to 0777), to be modified by the current umask.
+(defaults to 0777)
 
 =back
 
@@ -72,33 +72,17 @@
 
 =item *
 
-a boolean value, which if TRUE will cause C to
-skip any files to which you do not have delete access
-(if running under VMS) or write access (if running
-under another OS).  This will change in the future when
-a criterion for 'delete permission' under OSs other
-than VMS is settled.  (defaults to FALSE)
+a boolean value, which if FALSE (the default for non-root users) will
+cause C to adjust the mode of directories (if required) prior
+to attempting to remove the contents.  Note that on interruption or
+failure of C, directories may be left with more permissive
+modes for the owner.
 
 =back
 
 It returns the number of files successfully deleted.  Symlinks are
 simply deleted and not followed.
 
-B There are race conditions internal to the implementation of
-C making it unsafe to use on directory trees which may be
-altered or moved while C is running, and in particular on any
-directory trees with any path components or subdirectories potentially
-writable by untrusted users.
-
-Additionally, if the third parameter is not TRUE and C is
-interrupted, it may leave files and directories with permissions altered
-to allow deletion (and older versions of this module would even set
-files and directories to world-read/writable!)
-
-Note also that the occurrence of errors in C can be determined I
-by trapping diagnostic messages using C<$SIG{__WARN__}>; it is not apparent
-from the return value.
-
 =head1 DIAGNOSTICS
 
 =over 4
@@ -124,8 +108,9 @@
 use Exporter ();
 use strict;
 use warnings;
+use Cwd 'getcwd';
 
-our $VERSION = "1.07";
+our $VERSION = "1.06";
 our @ISA = qw( Exporter );
 our @EXPORT = qw( mkpath rmtree );
 
@@ -172,111 +157,150 @@
 @created;
 }
 
-sub rmtree {
-my($roots, $verbose, $safe) = @_;
-my(@files);
-my($count) = 0;
-$verbose ||= 0;
-$safe ||= 0;
-
-if ( defined($roots) && length($roots) ) {
-  $roots = [$roots] unless ref $roots;
-}
-else {
-  carp "No root path(s) specified\n";
-  return 0;
-}
-
-my($root);
-foreach $root (@{$roots}) {
-   if ($Is_MacOS) {
-   $root = ":$root" if $root !~ /:/;
-   $root =~ s#([^:])\z#$1:#;
-   } else {
-   $root =~ s#/\z##;
-   }
-   (undef, undef, my $rp) = lstat $root or next;
-   $rp &= 0;   # don't forget setuid, setgid, sticky bits
-   if ( -d _ ) {
-   # notabene: 0700 is for making readable in the first place,
-   # it's also intended to change it to writable in case we have
-   # to recurse in which case we are better than rm -rf for 
-   # subtrees with strange permissions
-   chmod($rp | 0700, ($Is_VMS ? VMS::Filespec::fileify($root) : $root))
- or carp "Can't make directory $root read+writeable: $!"
-   unless $safe;
-
-   if (opendir my $d, $root) {
-   no strict 'refs';
-   if (!defined ${"\cTAINT"} or ${"\cTAINT"}) {
-   # Blindly untaint dir names
-   @files = map { /^(.*)$/s ; $1 } readdir $d;
-   } else {
-   @files = readdir $d;
-   }
-   closedir $d;
-   }
-   else {
-   carp "Can't read $root: $!";
-   @files = ();
-   }
-
-   # Deleting large numbers of files from VMS Files-11 filesystems
-   # is faster if done in reverse ASCIIbetical order 
-   @files = reverse @files if $Is_VMS;
-   ($root = VMS::Filespec::unixify($root)) =~ s#\.dir\z## if $Is_VMS;
-   if ($Is_MacOS) {
-   @files = map("$root$_", @files);
-   } else {
-   @files = map("$root/$_", grep $_!~/^\.{1,2}\z/s,@files);
-   }
-   $count += rmtree([EMAIL PROTECTED],$verbose,$safe);
-   if ($safe &&
-   ($Is_VMS ? !&VMS::Filespec::candelete($root) : !-w $root)) {
-   print "skipped $root\n" if $verbose;
-   next;
-  

RE: Creating your own FH interface -- intended behavour?

[Paul Marquess]

From: Jos I. Boumans [mailto:[EMAIL PROTECTED]
 
> Hi,
> 
> i was happily programming along, and in the course of events found the
> need to have
> an FH like interface, with a custom backend. I found that these two
> invocations, on
> the same object do not produce the same result:
> 
>   $obj->readline vs <$obj>
> 
> It only does what i expect in the former case, not the latter:
> 
>  sub X::readline { 1 };
>  $x = bless {}, 'X';
>  print "rl ". $x->readline . $/;
>  print "<> ". <$x> . $/;
>  rl 1
>  Not a GLOB reference at - line 4.
> 
> As it seems, it calls the builtin readline() on <>, rather than the
> class' readline():
> 
>  BEGIN { *CORE::GLOBAL::readline = sub { 2 }; }
>  sub X::readline { 1 };
>  $x = bless {}, 'X';
>  print "rl ". $x->readline . $/;
>  print "<> ". <$x> . $/;
>  rl 1
>  <> 2
> 
> This doens't seem to DWIM. And although i've now found how i can make
> happen what
> i want, it seems an inelegant solution at best.
> 
> Any thoughts?

You need a self-tie. Have a look at IO::String for a good example of how to
do it.

Paul





___ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail 
http://uk.messenger.yahoo.com

Re: Creating your own FH interface -- intended behavour?

[Gisle Aas]

"Jos I. Boumans" <[EMAIL PROTECTED]> writes:

> Any thoughts?

You need to tie the filehandle and override the READLINE method.

--Gisle

Re: NaN on platforms that don't support it

[John Peacock]

Sisyphus wrote:

Oh, I think I understand  it's partly a case of inaccuracies in the
perlop, perlfunc and perldata documentation of NaN and Infinity. (The
documentation is a little ahead of itself :-)

Until NaN and Infinity are properly implemented, I believe it would be best
if perl reverted to treating these symbols simply as strings (as was the
case with 5.6).


I'm guessing that the problem is that on some platforms it is almost 
impossible to generate the requisite special number format (since some 
FPU's treat attempts at 0/0 to be a hardware fault and throw a hardware 
exception).  So even though IEEE 758 specifies these values:


http://docs.sun.com/source/806-3568/ncg_goldberg.html

(see Table D-2), it may not be possible to provide a general way to 
create that value without deep knowledge of the specific hardware being 
used.


John

Re: Smoke [5.9.3] 25217 FAIL(F) hp-ux 10.20 (PA-2.0/32/1 cpu)

[H.Merijn Brand]

On Mon, 25 Jul 2005 13:46:06 +0100, Nicholas Clark <[EMAIL PROTECTED]> wrote:

> On Mon, Jul 25, 2005 at 02:42:25PM +0200, H.Merijn Brand wrote:
> > On Mon, 25 Jul 2005 08:44 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]>
> > wrote:
> > 
> > > Failures: (common-args) none
> > > [stdio/perlio/univ.utf8] 
> > > [stdio/perlio/univ.utf8] -DDEBUGGING
> > > [stdio/perlio/univ.utf8] -Duseithreads
> > > [stdio/perlio/univ.utf8] -DDEBUGGING -Duseithreads
> > > ../ext/POSIX/t/sigaction.t..FAILED 26-30
> > 
> > Change 25223 by [EMAIL PROTECTED] on 2005/07/25 11:47:03
> > 
> > use POSIX might not throw an error. Check for useful values also
> 
> Why doesn't it?
> 
> Is this a different bug?
> 
> > < eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN + SIGRTMAX';
> > < skip("no SIGRT signals", 4) if $@;
> > < ok(SIGRTMAX > SIGRTMIN, "SIGRTMAX > SIGRTMIN");
> > ---
> > > eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN() +
> > > SIGRTMAX()'; skip("no SIGRT signals", 4) if $@ || SIGRTMIN() < 0 ||
> > > SIGRTMAX() < 0; ok(SIGRTMAX() > SIGRTMIN(), "SIGRTMAX > SIGRTMIN");
> 
> Or is it successfully exporting SIGRTMIN and SIGRTMAX, and the constants
> both have the value -1?

Yes, both are -1 (on HP-UX 10.20)

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: Smoke [5.9.3] 25217 FAIL(F) hp-ux 10.20 (PA-2.0/32/1 cpu)

[Nicholas Clark]

On Mon, Jul 25, 2005 at 02:42:25PM +0200, H.Merijn Brand wrote:
> On Mon, 25 Jul 2005 08:44 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> 
> > Failures: (common-args) none
> > [stdio/perlio/univ.utf8] 
> > [stdio/perlio/univ.utf8] -DDEBUGGING
> > [stdio/perlio/univ.utf8] -Duseithreads
> > [stdio/perlio/univ.utf8] -DDEBUGGING -Duseithreads
> > ../ext/POSIX/t/sigaction.t..FAILED 26-30
> 
> Change 25223 by [EMAIL PROTECTED] on 2005/07/25 11:47:03
> 
> use POSIX might not throw an error. Check for useful values also

Why doesn't it?

Is this a different bug?

> < eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN + SIGRTMAX';
> < skip("no SIGRT signals", 4) if $@;
> < ok(SIGRTMAX > SIGRTMIN, "SIGRTMAX > SIGRTMIN");
> ---
> > eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN() + SIGRTMAX()';
> > skip("no SIGRT signals", 4) if $@ || SIGRTMIN() < 0 || SIGRTMAX() < 0;
> > ok(SIGRTMAX() > SIGRTMIN(), "SIGRTMAX > SIGRTMIN");

Or is it successfully exporting SIGRTMIN and SIGRTMAX, and the constants both
have the value -1?

Nicholas Clark

Re: Smoke [5.9.3] 25217 FAIL(F) hp-ux 10.20 (PA-2.0/32/1 cpu)

[H.Merijn Brand]

On Mon, 25 Jul 2005 08:44 +0200, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:

> Failures: (common-args) none
> [stdio/perlio/univ.utf8] 
> [stdio/perlio/univ.utf8] -DDEBUGGING
> [stdio/perlio/univ.utf8] -Duseithreads
> [stdio/perlio/univ.utf8] -DDEBUGGING -Duseithreads
> ../ext/POSIX/t/sigaction.t..FAILED 26-30

Change 25223 by [EMAIL PROTECTED] on 2005/07/25 11:47:03

use POSIX might not throw an error. Check for useful values also

Affected files ...

... //depot/perl/ext/POSIX/t/sigaction.t#13 edit

Differences ...

 //depot/perl/ext/POSIX/t/sigaction.t#13 (text) 

182,184c182,184
< eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN + SIGRTMAX';
< skip("no SIGRT signals", 4) if $@;
< ok(SIGRTMAX > SIGRTMIN, "SIGRTMAX > SIGRTMIN");
---
> eval 'use POSIX qw(%SIGRT SIGRTMIN SIGRTMAX); SIGRTMIN() + SIGRTMAX()';
> skip("no SIGRT signals", 4) if $@ || SIGRTMIN() < 0 || SIGRTMAX() < 0;
> ok(SIGRTMAX() > SIGRTMIN(), "SIGRTMAX > SIGRTMIN");

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: NaN on platforms that don't support it

[Dominic Dunlop]

On 2005–07–25, at 12:42, John Peacock wrote:

Sisyphus wrote:

But on the 2 machines I ran that code on (linux and Win32), IEEE  
NaN is not

supported - as evidenced by the fact that NaN + 1 == 1.



NaN is supported on both of those platforms (AFAIK), but the string  
"NaN" is not a canonical way to generate the special IEEE NaN number.


Depends whose canon -- it's part of the 1999 C standard, but it's not  
in the 1989 version.


I think it's not unreasonable to expect perl to do the right thing if  
the underlying FP implementation allows it to. The 1999 C standard  
(or rather the late committee draft I have to hand) says for wcstof()  
(which defines how scanf() handles FP):


BEGIN EXTRACT
The expected form of the subject sequence [that is, the candidate  
string representation of a floating point number] is an optional plus  
or minus sign, then one of the following:


—a nonempty sequence of decimal digits optionally containing a  
decimal-point wide character, then an optional exponent part as  
defined for the corresponding single-byte characters in 6.4.4.2;
—a 0x or 0X, then a nonempty sequence of hexadecimal digits  
optionally containing a decimal-point wide character, then an  
optional binary-exponent part as defined in 6.4.4.2, where either the  
decimal-point wide character or the binary-exponent part is present;
—one of INF or INFINITY, or any other wide string equivalent except  
for case
—one of NAN or NAN(n-wchar-sequence opt), or any other wide string  
equivalent except for case in the NAN part, where:

n-wchar-sequence:
digit
nondigit
n-wchar-sequence digit
n-wchar-sequence nondigit

The subject sequence is defined as the longest initial subsequence of  
the input wide string, starting with the first non-white-space wide  
character, that is of the expected form. The subject sequence  
contains no wide characters if the input wide string is not of the  
expected form.

END EXTRACT

The Single UNIX Standard has the same thing at www.opengroup.org/onlinepubs/009695399/functions/wcstof.html>.


I know. Patches welcome...
--
Dominic Dunlop

Smoke [5.9.3] 25218 FAIL(XF) bsd/os 4.1 (i386/1 cpu)

[kane]

Automated smoke report for 5.9.3 patch 25218
fixit.xs4all.nl: Pentium II (i386/1 cpu)
onbsd/os - 4.1
using cc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
smoketime 3 hours 55 minutes (average 1 hour 57 minutes)

Summary: FAIL(XF)

O = OK  F = Failure(s), extended report at the bottom
X = Failure(s) under TEST but not under harness
? = still running or test results not (yet) available
Build failures during:   - = unknown or N/A
c = Configure, m = make, M = make (after miniperl), t = make test-prep

   25218 Configuration (common) none
--- -
F F - - -Duse64bitint
X O - - 
| | | +- PERLIO = perlio -DDEBUGGING
| | +--- PERLIO = stdio  -DDEBUGGING
| +- PERLIO = perlio
+--- PERLIO = stdio


Failures: (common-args) none
[stdio/perlio] -Duse64bitint
../t/op/int.t...FAILED 11
Inconsistent test results (between TEST and harness):
../lib/Net/hostent.tFAILED at test 4

[stdio] 
Inconsistent test results (between TEST and harness):
../lib/Net/hostent.tFAILED at test 4

-- 
Report by Test::Smoke v1.19_67 build 842 running on perl 5.00503
(Reporter v0.019 / Smoker v0.023)

Re: NaN on platforms that don't support it

[Sisyphus]

- Original Message - 
From: "John Peacock" <[EMAIL PROTECTED]>
To: "Sisyphus" <[EMAIL PROTECTED]>
Cc: "p5p" 
Sent: Monday, July 25, 2005 8:42 PM
Subject: Re: NaN on platforms that don't support it


> Sisyphus wrote:
> > But on the 2 machines I ran that code on (linux and Win32), IEEE NaN is
not
> > supported - as evidenced by the fact that NaN + 1 == 1.
>
> NaN is supported on both of those platforms (AFAIK),

Aaaah - I half expected it would be - but the perlop documentation implied
that's not the case.

> but the string "NaN" is not
> a canonical way to generate the special IEEE NaN number.
>

I also tried using NaN as a bareword. It makes no difference to the
behaviour - unless we 'use strict;' in which case the bareword is simply not
allowed.

> > I also checked by
> > running (as suggested in perlop):
> >
> > perl -le '$a = NaN; print "No NaN support here" if $a == $a'
>
> I don't see support for that construct in the code at all (there is
special INF
> and NaN handling in numeric.c:Perl_grok_number but this only bypasses the
> warning and doesn't affect the math), so I'm not sure that was ever
anything
> more than wishful thinking.  I think the thought was that there would be
special
> handling so that this:
>
> $x = NaN; # note bareword not string
>
> would autogenerate an actual NaN number, but it doesn't exist (AFAICT) in
toke.c
> where it belongs.
>

Oh, I think I understand  it's partly a case of inaccuracies in the
perlop, perlfunc and perldata documentation of NaN and Infinity. (The
documentation is a little ahead of itself :-)

Until NaN and Infinity are properly implemented, I believe it would be best
if perl reverted to treating these symbols simply as strings (as was the
case with 5.6).

It has been subsequently suggested on the c.l.p.misc thread that I should
submit a 'perlbug' report about this. Should I do that ?

Thanks John.

Cheers,
Rob

Creating your own FH interface -- intended behavour?

[Jos I. Boumans]

Hi,

i was happily programming along, and in the course of events found the 
need to have
an FH like interface, with a custom backend. I found that these two 
invocations, on

the same object do not produce the same result:

$obj->readline vs <$obj>

It only does what i expect in the former case, not the latter:

sub X::readline { 1 };
$x = bless {}, 'X';
print "rl ". $x->readline . $/;
print "<> ". <$x> . $/;
rl 1
Not a GLOB reference at - line 4.

As it seems, it calls the builtin readline() on <>, rather than the 
class' readline():


BEGIN { *CORE::GLOBAL::readline = sub { 2 }; }
sub X::readline { 1 };
$x = bless {}, 'X';
print "rl ". $x->readline . $/;
print "<> ". <$x> . $/;
rl 1
<> 2

This doens't seem to DWIM. And although i've now found how i can make 
happen what

i want, it seems an inelegant solution at best.

Any thoughts?

--

Jos Boumans

I won't insult your intelligence by suggesting that you
really believe what you just said.
--William Buckley, Jr.

CPANPLUShttp://cpanplus.sf.net

Re: NaN on platforms that don't support it

[John Peacock]

Sisyphus wrote:

But on the 2 machines I ran that code on (linux and Win32), IEEE NaN is not
supported - as evidenced by the fact that NaN + 1 == 1. 


NaN is supported on both of those platforms (AFAIK), but the string "NaN" is not 
a canonical way to generate the special IEEE NaN number.



I also checked by
running (as suggested in perlop):

perl -le '$a = NaN; print "No NaN support here" if $a == $a'


I don't see support for that construct in the code at all (there is special INF 
and NaN handling in numeric.c:Perl_grok_number but this only bypasses the 
warning and doesn't affect the math), so I'm not sure that was ever anything 
more than wishful thinking.  I think the thought was that there would be special 
handling so that this:


$x = NaN; # note bareword not string

would autogenerate an actual NaN number, but it doesn't exist (AFAICT) in toke.c 
where it belongs.


However, Tels did add this support to bigint:

use bigint;
$x = NaN;
$x += 1;

$y = "foo";
$y += 1;

print $x, " ", $y, "\n";
__END__

produces the expected (or not in the second case):

NaN NaN

HTH

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

Re: [PATCH ext/POSIX/POSIX.pod] POSIX::SigAction

[H.Merijn Brand]

On Sat, 23 Jul 2005 02:39:47 +0200, Abigail <[EMAIL PROTECTED]> wrote:

> 
> The documentation said the first argument of the constructor needs
> to be the fully qualified name, but the example uses a reference to
> the handler, not the name. And since using a reference seems to work
> as well, this patch documents it.

The code has chanched after your patch, so it will not apply.
As I read the patch, I don't know if it would still be valid.

The chunk currently reads:

--8<---
=item new

Creates a new C object which corresponds to the C
C.  This object will be destroyed automatically when
it is no longer needed.  The first parameter is the handler, a sub
reference.  The second parameter is a C object, it
defaults to the empty set.  The third parameter contains the
C, it defaults to 0.

$sigset = POSIX::SigSet->new(SIGINT, SIGQUIT);
$sigaction = POSIX::SigAction->new( \&handler, $sigset, 
&POSIX::SA_NOCLDSTOP );

This C object is intended for use with the 
C
function.
-->8---

> Abigail
> 
> 
> --- ext/POSIX/POSIX.pod.orig  Sat Feb  5 17:56:13 2005
> +++ ext/POSIX/POSIX.pod   Sat Jul 23 02:35:11 2005
> @@ -1635,13 +1635,14 @@
>  
>  Creates a new C object which corresponds to the C
>  C.  This object will be destroyed automatically when it
> is -no longer needed.  The first parameter is the fully-qualified name of a
> sub -which is a signal-handler.  The second parameter is a C
> -object, it defaults to the empty set.  The third parameter contains the
> -C, it defaults to 0.
> +no longer needed.  The first parameter is either the fully-qualified name
> +of a sub which is a signal-handler, or a reference to it. The second
> parameter +is a C object, it defaults to the empty set. The
> third +parameter contains the C, it defaults to 0.
>  
>   $sigset = POSIX::SigSet->new(SIGINT, SIGQUIT);
> - $sigaction = POSIX::SigAction->new( \&main::handler, $sigset,
> &POSIX::SA_NOCLDSTOP );
> + $sigaction = POSIX::SigAction->new( \&main::handler,
> +$sigset, &POSIX::SA_NOCLDSTOP );
>  
>  This C object is intended for use with the
> C function.

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: perlfunc sez crypt() encrypts... but it doesn't.

[Nicholas Clark]

On Sun, Jul 24, 2005 at 11:17:10PM -0400, Garry Williams wrote:
> On Sun, 2005-07-24 at 21:59 -0500, David Nicol wrote:
> > How about using the word "obfuscate?"  It's a nice word
> 
> Eschew obfuscation.

perl -MCPAN -e"install B::Deobfuscate"

Nicholas Clark

Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts

[H.Merijn Brand]

On Sun, 24 Jul 2005 13:49:25 -0700, Michael G Schwern <[EMAIL PROTECTED]>
wrote:

> On Sun, Jul 24, 2005 at 02:03:31PM -0400, Ronald J Kimball wrote:
> > Personally, I don't like the new documentation in this patch.  It seems to
> > put the focus more on correcting the issue about encryption, rather than
> > actually documenting what crypt() does.

I have applied the combo of these two as change #25220
In the future I'd prefer a *new* patch that would overrule the first (unless
that was already applied and acknowledged to the list). Now I had to apply
the first before applying the second.

> There's much less change then there seems from the patch.  Most of it is
> whitespace movement.  The 2nd and 3rd paragraphs are mostly new, expanding
> on points made in the original 2nd paragraph.  Everythig below paragraph #3
> is all but untouched.  The password example has been expanded to show how 
> having a one way crypt that doesn't work well with with large chunks of 
> data is useful.
> 
> It adds the particularly important points about crypt() that:
> 
> * The same PLAINTEXT and SALT will always return the same value
> * You cannot recover the PLAINTEXT from the digest
> * Small changes to the PLAINTEXT or SALT will result in large changes in
>   the digest.
> * The SALT is visible in the digest.
> * Its primarily used to check the equality of two strings when you don't
>   want to transmit those strings.
> 
> I think this better documents what crypt() does and how its useful without
> assuming the reader already understands hashing.
> 
> 
> > Furthermore, "extirpated" and "munition" in the opening paragraph?  The
> > perl documentation should be readable to people with various levels of
> > experience with programming and with English.  (Don't use a long word
> > where a diminutive one will do.)
> 
> Don't blame me, that was already there.  Its been there since 5.002.  I had 
> to look up extirpated, too.
> 
> 
> > In CS terms, I always thought of digest as a noun; as a verb it suggests
> > to me the intestines.  :) I would write something like "Creates a digest"
> > instead.
> 
> My verbing the "digest" noun results from trying to avoid "hashing".  The
> first paragraph is the only place that happens so I'll change it per
> your suggestion.
> 
> 
> > The second paragraph in the existing documentation seems to explain the
> > issue clearly anyway.
> 
> Sure it does, you have a CS background and already know what a digest is
> and how crypt works. :)
> 
> Attached is a patch with some improvements after reading it through again.
> 
> * Move the mentioning of Crypt modules on CPAN up to the point where we
>   explain crypt() is not about cryptography instead of at the end.
> * Mention Digest.pm rather than Crypt:: modules in the section about how
>   crypt() isn't a particuarly robust hashing algorithm because A) Digest
>   comes with Perl and B) we're talking about more robust digesting
>   algorithms, not encryption.
> * Explain why you feed the digest in as the salt a little better.
> * Stop verbing "digest".
> 
> 


-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [perl #36645] INSTALLATION OF PERL 5.8.7

[Rafael Garcia-Suarez]

Brezovec, Dick wrote:
> > You may give one or more space-separated answers, or "none" if appropriate.
> > A well-behaved OS will have no hints, so answering "none" or just "Policy"
> > is a good thing.  DO NOT give a wrong version or a wrong OS.
> > 
> > Which of these apply, if any? [solaris_2] solaris_8
> > solaris_8.sh does not exist
> > hint to use instead? [solaris_8] none

I think you should try with solaris_2 here. The shell script says :

# For consistency with gcc, we do not adopt Sun Marketing's
# removal of the '2.' prefix from the Solaris version number.
# (Configure tries to detect an old fixincludes and needs
# this information.)

Usually Configure runs just fine when you accept the defaults.

Re: [PATCH] perlfunc.pod: s/definetely/definitely/

[H.Merijn Brand]

On Sun, 24 Jul 2005 12:55:09 +0200, "Piotr Fusik" <[EMAIL PROTECTED]> wrote:

> I googled "definetely" and it seems to be widely used.
> But I found this:
> http://wikitravel.org/en/Wikitravel:List_of_common_misspellings

My spell checker agreed. Typo changed in #25219

> --- perl-current/pod/perlfunc.pod Sun Jul 24 11:30:36 2005
> +++ perl-patched/pod/perlfunc.pod Sun Jul 24 12:26:12 2005
> @@ -3707,7 +3707,7 @@
>  platforms are using IEEE, there may be subtle differences.  Being able
>  to use C> or C> on floating point values can be very useful,
>  but also very dangerous if you don't know exactly what you're doing.
> -It is definetely not a general way to portably store floating point
> +It is definitely not a general way to portably store floating point
>  values.
>  
>  When using C> or C> on an C<()>-group, this will affect

-- 
H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/)
using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2  on HP-UX 10.20, 11.00 & 11.11,
 AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn
Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org
 reports  to: [EMAIL PROTECTED],perl-qa@perl.org

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

Ok,

Here are the patches to vms.c and vmsish.h that when combined with the 
other patches that I have posted will allow bleadperl to compile on VMS 
up to the creation of miniperl.


I did not include the fix for the buffer high-water mark overrun as my 
notes on that are at work.


The link of miniperl is failing because of an undefined symbol in the 
transfer vector.


"Perl_stashpv_hvname_match".

It appears that when USE_ITHREADS is not defined, either that transfer 
vector entry should not be written for VMS, or a stub routine should be 
present either in util.c or vms.c


This is all I have time for tonight.

-John
[EMAIL PROTECTED]
Personal Opinion Only

--- vms/vms.c_blead Sun Jul 24 22:37:24 2005
+++ vms/vms.c   Sun Jul 24 22:27:36 2005
@@ -1005,12 +1005,12 @@
 
 
 static char *mp_do_rmsexpand(pTHX_ char *, char *, int, char *, unsigned);
-static char *mp_do_fileify_dirspec(pTHX_ char *, char *, int);
-static char *mp_do_tovmsspec(pTHX_ char *, char *, int);
+static char *mp_do_fileify_dirspec(pTHX_ const char *, char *, int);
+static char *mp_do_tovmsspec(pTHX_ const char *, char *, int);
 
 /*{{{int do_rmdir(char *name)*/
 int
-Perl_do_rmdir(pTHX_ char *name)
+Perl_do_rmdir(pTHX_ const char *name)
 {
 char dirfile[NAM$C_MAXRSS+1];
 int retval;
@@ -1034,7 +1034,7 @@
  */
 /*{{{int kill_file(char *name)*/
 int
-Perl_kill_file(pTHX_ char *name)
+Perl_kill_file(pTHX_ const char *name)
 {
 char vmsname[NAM$C_MAXRSS+1], rspec[NAM$C_MAXRSS+1];
 unsigned long int jpicode = JPI$_UIC, type = ACL$C_FILE;
@@ -1135,7 +1135,7 @@
 
 /*{{{int my_mkdir(char *,Mode_t)*/
 int
-Perl_my_mkdir(pTHX_ char *dir, Mode_t mode)
+Perl_my_mkdir(pTHX_ const char *dir, Mode_t mode)
 {
   STRLEN dirlen = strlen(dir);
 
@@ -1158,7 +1158,7 @@
 
 /*{{{int my_chdir(char *)*/
 int
-Perl_my_chdir(pTHX_ char *dir)
+Perl_my_chdir(pTHX_ const char *dir)
 {
   STRLEN dirlen = strlen(dir);
 
@@ -2947,7 +2947,7 @@
  * rmesexpand() returns the address of the resultant string if
  * successful, and NULL on error.
  */
-static char *mp_do_tounixspec(pTHX_ char *, char *, int);
+static char *mp_do_tounixspec(pTHX_ const char *, char *, int);
 
 static char *
 mp_do_rmsexpand(pTHX_ char *filespec, char *outbuf, int ts, char *defspec, 
unsigned opts)
@@ -3126,7 +3126,7 @@
  */
 
 /*{{{ char *fileify_dirspec[_ts](char *path, char *buf)*/
-static char *mp_do_fileify_dirspec(pTHX_ char *dir,char *buf,int ts)
+static char *mp_do_fileify_dirspec(pTHX_ const char *dir,char *buf,int ts)
 {
 static char __fileify_retbuf[NAM$C_MAXRSS+1];
 unsigned long int dirlen, retlen, addmfd = 0, hasfilename = 0;
@@ -3140,9 +3140,8 @@
 dirlen = strlen(dir);
 while (dirlen && dir[dirlen-1] == '/') --dirlen;
 if (!dirlen) { /* We had Unixish '/' -- substitute top of current tree */
-  strcpy(trndir,"/sys$disk/00");
-  dir = trndir;
-  dirlen = 16;
+  dir = "/sys$disk";
+  dirlen = 9;
 }
 if (dirlen > NAM$C_MAXRSS) {
   set_errno(ENAMETOOLONG); set_vaxc_errno(RMS$_SYN); return NULL;
@@ -3154,36 +3153,39 @@
 trnlnm_iter_count++; 
 if (trnlnm_iter_count >= PERL_LNM_MAX_ITER) break;
   }
-  dir = trndir;
-  dirlen = strlen(dir);
+  dirlen = strlen(trndir);
 }
 else {
   strncpy(trndir,dir,dirlen);
   trndir[dirlen] = '\0';
-  dir = trndir;
 }
+
+/* At this point we are done with *dir and use *trndir which is a
+ * copy that can be modified.  *dir must not be modified.
+ */
+
 /* If we were handed a rooted logical name or spec, treat it like a
  * simple directory, so that
  *$ Define myroot dev:[dir.]
  *... do_fileify_dirspec("myroot",buf,1) ...
  * does something useful.
  */
-if (dirlen >= 2 && !strcmp(dir+dirlen-2,".]")) {
-  dir[--dirlen] = '\0';
-  dir[dirlen-1] = ']';
+if (dirlen >= 2 && !strcmp(trndir+dirlen-2,".]")) {
+  trndir[--dirlen] = '\0';
+  trndir[dirlen-1] = ']';
 }
-if (dirlen >= 2 && !strcmp(dir+dirlen-2,".>")) {
-  dir[--dirlen] = '\0';
-  dir[dirlen-1] = '>';
+if (dirlen >= 2 && !strcmp(trndir+dirlen-2,".>")) {
+  trndir[--dirlen] = '\0';
+  trndir[dirlen-1] = '>';
 }
 
-if ((cp1 = strrchr(dir,']')) != NULL || (cp1 = strrchr(dir,'>')) != NULL) {
+if ((cp1 = strrchr(trndir,']')) != NULL || (cp1 = strrchr(trndir,'>')) != 
NULL) {
   /* If we've got an explicit filename, we can just shuffle the string. */
   if (*(cp1+1)) hasfilename = 1;
   /* Similarly, we can just back up a level if we've got multiple levels
  of explicit directories in a VMS spec which ends with directories. */
   else {
-for (cp2 = cp1; cp2 > dir; cp2--) {
+for (cp2 = cp1; cp2 > trndir; cp2--) {
   if (*cp2 == '.') {
 *cp2 = *cp1; *cp1 = '\0';
 hasfilename = 1;
@@ -3194,26 +3196,26 @@
   }
 }
 
-if (hasfilename || !strpbrk(dir,"]:>")) { /* Unix-style path or fil

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

Michael G Schwern wrote:

On Sun, Jul 24, 2005 at 08:57:52PM -0400, John E. Malmberg wrote:

Might I suggest you check your local copies of Perl into a local version
control system?  I usually use RCS for small changes to small groups of files
or I dump the whole thing into darcs for larger changes.


I was not intending on working on bleadperl, or doing any perl 
development at home.  It is just that this bug report kept showing up on 
the vmsperl list, and fixing this type of bug is usually more trivial 
than it turned out to be.


So I got sucked in, and was unprepared :-)

I do not have remote access to the work system, so if the code is there, 
I do not have access to it until Monday.


I only put in a modified copy here last week in case I got around to 
using one of the Perl scripts that potentially need it.


Now that I have a copy of bleadperl pretty much almost linking, I should 
be able to keep it running.


I really need to get my copy of rsync fixed though.  The quick and dirty 
hacked version has some strange bugs.


I think that Craig can verify that I am probably the only one running 
rsync on VMS at all.


Craig, if you can still build your snapshot of rsync I posted earlier, 
modifying the pthread attributes before the thread creation to have a 
stack of about 32K should hide many of the problems.


One of these days I need to get a LINUX system set up here.

-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

John E. Malmberg wrote:

John E. Malmberg wrote:
 
Next on the list that pp_ctl.c is is trying to pass a string constant to 
 tounixpath() and tounixname() to be converted to a UNIX name.


 From the code optimization issue, it is better if I can just add a 
const  qualifier to the routines in VMS.C.  I can try putting such a 
qualifier in the header files and VMS.C and see what shakes out when 
VMS.C gets compiled.


Ok, I got to VMS.C.  It and vmsish.h are going to need a bit of fixes in 
order to work with the rest of Perl.


Mostly fixing it so that it has the const qualifiers that Perl expects 
the wrapper and OS specific routines to have, and that also means making 
sure that those routines to not modify them.


Each pass through is revealing more routines that have either have to 
maintain the const attribute or make a copy of the data.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

Michael G Schwern wrote:

On Sun, Jul 24, 2005 at 07:58:27PM -0400, John E. Malmberg wrote:


Has VMS.C changed any from Perl 5.8.7?


Between bleadperl and 5.8.7?  Yes.  Looks like mostly elimination of
5.005threads and consting and some of that char * casting you don't like.

You can get a copy of bleadperl via FTP, rsync is just more convenient.
ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current/


I have a copy of bleadperl that I pulled down by rsync this morning 
before I left to watch one of the local minor league teams grasp defeat 
from the jaws of victory.


What I do not have locally is an unpacked copy of unmodified 5.8.6 or 
5.8.7.  The local copies on this system already have my ODS-5, UNIX, and 
POSIX fixes, so I do not have a quick way to do a diff, and vms.c got 
significant changes.  And since then I have discovered a small buffer 
highwater mark overrun in the original code.  That fix is also only on 
my work copy.


All of that reference stuff is on the work server where I did the changes.

I was just trying to see if I could get this fixed quickly, while I 
worked on getting the current "blead" rsync to actually run using Posix 
Threads.


Removing the consting is not a good thing unless the caller of the 
routine is expecting the value to be modified.  More consting is better 
for optimizing compilers, particularly if their target is a CPU with 
pipelining and lots of registers, which is the situation for Alpha and I64.


And that includes numeric constants, where a numeric location is 
initialized at compile time, and never changed by the code.  Putting a 
const qualifier on it can make the resulting code more efficient. 
Particularly if the variable has scope outside of the module it is 
defined in.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

John E. Malmberg wrote:

Abe Timmerman wrote:



Hi all,

Blead on VMS is still not building. This is on the hp-testdrive 
machine SPE180:


CC/DECC/NOANSI_ALIAS 
/Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/

NoList/float=ieee/ieee=denorm/Define=PERL_CORE DOIO.C

if (UNLINK(s))
^
%CC-W-NOTCONSTQUAL, In this statement, the referenced type of the 
pointer value "(s)" is const, but the referenced type of the target of 
this assignment is not.

at line number 1838 in file USER1:[ABELTJE.PERL-CURRENT]DOIO.C;1


This requires fixing in multiple places.

perl.h, util.c, and embed.fnc, and this seems to require a running perl 
to rebuild proto.h


There is also an ext/Devel.PPPort/parts/embed.fnc that has a reference. 
 A look at this file shows that it appears to be a few generations 
behind embed.fnc.


This will get the build to the next compiler warning which is the VMS 
specific code in mg.c.


The VMS specific code is modifying what the compiler has been told is a 
pointer to a constant, instead of making a copy and then modifying it.


It is quite possible that the Perl_my_getenv() could actually return a 
pointer to non-writable memory, so if this compiler warning is 
suppressed here, it could lead to an access violation at run time.


-John
[EMAIL PROTECTED]
Personal Opinion Only


3472c3472
< I32 unlnk (char*);
---
> I32 unlnk (const char*);
835c835
< Ap|I32|unlnk  |NN char* f
---
> Ap|I32|unlnk  |NN const char* f
1566c1566
< Perl_unlnk(pTHX_ char *f) /* unlink all versions of a file */
---
> Perl_unlnk(pTHX_ const char *f)   /* unlink all versions of a file */

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

John E. Malmberg wrote:

Craig A. Berry wrote:


At 5:48 PM -0400 7/24/05, John E. Malmberg wrote:



  if (UNLINK(s))
^
%CC-W-NOTCONSTQUAL, In this statement, the



And this should take care of it. Accidentally left out of my patch of 




I would strongly recommend the patch that I posted before I received this.


I accidentally left off the "-u" from GNU diff, these have the patches 
in unified diff format.


Also is what I think is the fix to mg.c to resolve where it may be 
attempting to modify read-only memory.


Next on the list that pp_ctl.c is is trying to pass a string constant to 
 tounixpath() and tounixname() to be converted to a UNIX name.


From the code optimization issue, it is better if I can just add a 
const  qualifier to the routines in VMS.C.  I can try putting such a 
qualifier in the header files and VMS.C and see what shakes out when 
VMS.C gets compiled.


Has VMS.C changed any from Perl 5.8.7?

-John
[EMAIL PROTECTED]
Personal Opinion Only

--- embed.fnc_blead Sun Jul 24 18:43:53 2005
+++ embed.fnc   Sun Jul 24 18:19:41 2005
@@ -832,7 +832,7 @@
 Apd|UV |to_utf8_title  |NN const U8 *p|NN U8* ustrp|NULLOK STRLEN *lenp
 Apd|UV |to_utf8_fold   |NN const U8 *p|NN U8* ustrp|NULLOK STRLEN *lenp
 #if defined(UNLINK_ALL_VERSIONS)
-Ap |I32|unlnk  |NN char* f
+Ap |I32|unlnk  |NN const char* f
 #endif
 Apd|I32|unpack_str |NN const char *pat|NN const char *patend|NN 
const char *s \
|NULLOK const char *strbeg|NN const char 
*strend|NULLOK char **new_s \
--- mg.c_blead  Sun Jul 24 19:40:43 2005
+++ mg.cSun Jul 24 19:40:29 2005
@@ -1045,10 +1045,13 @@
MgTAINTEDDIR_off(mg);
 #ifdef VMS
if (s && klen == 8 && strEQ(ptr, "DCL$PATH")) {
-   char pathbuf[256], eltbuf[256], *cp, *elt = s;
+   char pathbuf[256], eltbuf[256], *cp, *elt;
Stat_t sbuf;
int i = 0, j = 0;
 
+   strncpy(eltbuf, s, 255);
+   eltbuf[255] = 0;
+   elt = eltbuf;
do {  /* DCL$PATH may be a search list */
while (1) {   /* as may dev portion of any element */
if ( ((cp = strchr(elt,'[')) || (cp = strchr(elt,'<'))) ) {
--- perl.h_bleadSun Jul 24 18:45:57 2005
+++ perl.h  Sun Jul 24 17:58:03 2005
@@ -3469,7 +3469,7 @@
 
 #ifdef UNLINK_ALL_VERSIONS /* Currently only makes sense for VMS */
 #define UNLINK unlnk
-I32 unlnk (char*);
+I32 unlnk (const char*);
 #else
 #define UNLINK PerlLIO_unlink
 #endif
--- util.c_bleadSun Jul 24 18:47:36 2005
+++ util.c  Sun Jul 24 17:57:56 2005
@@ -1563,7 +1563,7 @@
 
 #ifdef UNLINK_ALL_VERSIONS
 I32
-Perl_unlnk(pTHX_ char *f)  /* unlink all versions of a file */
+Perl_unlnk(pTHX_ const char *f)/* unlink all versions of a file */
 {
 I32 i;
 

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

Craig A. Berry wrote:

At 5:48 PM -0400 7/24/05, John E. Malmberg wrote:



  if (UNLINK(s))
^
%CC-W-NOTCONSTQUAL, In this statement, the


And this should take care of it. Accidentally left out of my patch of two hours 
ago.
 
--- doio.c_orig Sat Jul 23 18:54:47 2005

+++ doio.c  Sat Jul 23 18:54:48 2005
@@ -1835,14 +1835,14 @@
s = SvPV_nolen_const(*mark);
APPLY_TAINT_PROPER();
if (PL_euid || PL_unsafe) {
-   if (UNLINK(s))
+   if (UNLINK((char *)s))


Please do not do that, you are possibly introducing either a silent data 
corrupter or an intermittent access violation.  Both of which may be 
hard to diagnose.


I would strongly recommend the patch that I posted before I received this.

The const modifier needs to be put on the unlink() wrappers, and the 
prototypes that reference it.


The const modifier is also an important part of compiler optimization 
and lint features.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

Craig A. Berry wrote:

At 11:00 PM -0400 7/24/05, John E. Malmberg wrote:


The link of miniperl is failing because of an undefined symbol in the transfer 
vector.

"Perl_stashpv_hvname_match".

It appears that when USE_ITHREADS is not defined, either that transfer vector 
entry should not be written for VMS, or a stub routine should be present either 
in util.c or vms.c



That was fixed in patch #25217:

http://public.activestate.com/cgi-bin/perlbrowse?patch=25217


I see it there at the bottom.

If I pull down a new bleadperl tomorrow, would that patch be present?

There is a problem with the other parts of the patch.

The (char *) casts are wrong and need to be removed.  They will cause 
data corruptions and access violations when the stars and the moon are 
not aligned perfectly.


It is deceptive because most calls will likely work, and it may even be 
able to get Perl built and pass the test suite, but it is still wrong.


The data corruptions may be hard to diagnose, but when one of the access 
violations hit, those will be obvious.  The calling routine has been 
promised that those data locations would not be modified by any 
subroutine, and the optimizer does take advantage of that.


Be highly suspicious of any code that is using a cast to get around a 
compiler const warning.  About the only time that is not a serious bug 
is when you are setting up a descriptor to be passed as a read-only 
parameter to a system service or run-time library call.


Adding the const qualifier to the input parameters and fixing the 
routines to not modify the input data is the safest way to resolve these 
issues, and when you look at the patches that I posted, there really was 
not that much to make the VMS specific code compliant with what the rest 
of Perl expects.


I posted patches for vmsish.h, vms/vms.c, embed.fnc, util.c, mg.c, and 
perl.h that fix the build issues with out causing those corruptions.


The embed.fnc requires that the proto.h file be regenerated per the 
instructions included in it, and as near as I can tell, the bleadperl 
built from a realclean state does not regenerate it on the fly.


The patch to descrip_mms.template is needed in order to have useful 
listings to diagnose some of these issues.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: What's holding up mainperl from upgrading MakeMaker?

[John E. Malmberg]

Michael G Schwern wrote:

On Sun, Jul 24, 2005 at 12:58:57PM -0500, Craig A. Berry wrote:


At 4:27 PM +0100 7/23/05, Nicholas Clark wrote:


However, VMS is currently failing to build even miniperl, due to its C
compiler being more stringent about const consistency than anything else
on the planet.


It's the same compiler as the Tru64 compiler, but the default options
on the build tools reflect the assumption that all warnings will be
fixed before proceeding.


Wow, it treats warnings as errors?  That's... ummm-- can you turn that off?


It is MMK/MMS that treats the warnings as errors.

I usually run with a higher level of warnings enabled on the compiler. 
That way it finds other errors, including "legal" code that has a high 
probability of having a bug.



I'm testing a patch against blead that should get it building again.


Craig,

Please look at the descrip_mms.template patch that I just sent along. 
With out it, the debug listings on VMS are not very useful.


-John
[EMAIL PROTECTED]
Personal Opinion Only

Re: [EMAIL PROTECTED] on OpenVMS (not good)

[John E. Malmberg]

Abe Timmerman wrote:

Hi all,

Blead on VMS is still not building. This is on the hp-testdrive machine 
SPE180:


CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/
NoList/float=ieee/ieee=denorm/Define=PERL_CORE DOIO.C

if (UNLINK(s))
^
%CC-W-NOTCONSTQUAL, In this statement, the referenced type of the pointer 
value "(s)" is const, but the referenced type of the target of this 
assignment is not.

at line number 1838 in file USER1:[ABELTJE.PERL-CURRENT]DOIO.C;1


Ok, I am reproducing the problem now.  There seems to be two different 
cases, one for if you build with -dunlink_all_versions and one with 
default.  My last build attempt was with -dunlink_all_versions.


In order to get more useful information in the listings when Perl is 
built in debug on OpenVMS, the following patch is needed.


It gives the assembler code, and shows all the macro expansions.  The 
second is what I need to track down what routines are missing the 
"const" modifier.


-John
[EMAIL PROTECTED]
Personal Opinion Only
--- vms/descrip_mms.template_blead  Sun Jul 24 17:29:21 2005
+++ vms/descrip_mms.templateSun Jul 24 17:33:34 2005
@@ -123,7 +123,7 @@
 .else
 XTRAOBJS = 
 LIBS1 = $(XTRAOBJS)
-DBGSPECFLAGS = /Show=All
+DBGSPECFLAGS = /Show=(expansion,include)/machine
 # Some versions of DECCRTL on AXP have a bug in chdir() which causes the change
 # to persist after the image exits, even when this was not requested, iff
 # SYSNAM is enabled.  This is fixed in CSC Patch # AXPACRT04_061, but turning

RE: [PATCH] blead help for VMS

[Paul Marquess]

From: Craig A. Berry [mailto:[EMAIL PROTECTED]

> The attached patch (plus one additional step) gets bleadperl building on
> VMS again. The additional step is renaming the directory
> 
> ext/Compress/Zlib/zlib-src-1.2.3
> 
> to
> 
> ext/Compress/Zlib/zlib-src
> 
> which I assume needs to be done in Perforce. The related changes to
> MANIFEST and ext/Compress/Zlib/config.in are in the patch. The dot is
> the directory delimiter on VMS, and although newer versions of VMS have
> ways to escape the dots when the non-default features for doing so are
> enabled, it's a heck of a lot easier to just avoid dots in directory
> names.

Hmmm, given the lack of VMS-related mail in my inbox, does this mean that
nobody has tried to install the latest Compress::Zlib on VMS since January?
C::Zlib-1.34 added a zlib-src-1.2.2 directory in January.

Anyway, I've updated my development copy to match your change.

Paul





___ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail 
http://uk.messenger.yahoo.com