Re: perlfunc sez crypt() encrypts... but it doesn't.
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. -- Garry Williams
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Sun, Jul 24, 2005 at 11:09:12PM -0400, Ronald J Kimball wrote: > Cool. I apologize for complaining about the parts that were already > there. You only have to apologize if you don't provide a patch. ;) -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml
Re: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 09:59:32PM -0500, David Nicol wrote: > How about using the word "obfuscate?" It's a nice word Or were you talking about a word to use instead of "encrypt"? In that case definately not. While obfuscation might be seen as a really weak form of encryption, its certainly not hashing. For one thing you can recover the original data from obfuscation. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
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 -- Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
Re: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 09:59:32PM -0500, David Nicol wrote:
> How about using the word "obfuscate?" It's a nice word
They don't mean the same thing.
>From The Collaborative International Dictionary of English v.0.44 [gcide]:
Extirpate \Ex"tir*pate\ (?; 277), v. t. [imp. & p. p.
{Extirpated}; p. pr. & vb. n. {Extirpating}.] [L. extirpatus,
exstirpatus, p. p. of extirpare, exstirpare; ex out + strips
stock, stem, root.]
To pluck up by the stem or root; to root out; to eradicate,
literally or figuratively; to destroy wholly; as, to
extirpate weeds; to extirpate a tumor; to extirpate a sect;
to extirpate error or heresy.
Syn: To eradicate; root out; destroy; exterminate;
annihilate; extinguish.
[1913 Webster]
I think "crippled" or "removed" would be fine.
Or we could delete the mention entirely as nobody considers crypt to be a
munition anymore... I hope. IANAL.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Insulting our readers is part of our business model.
http://somethingpositive.net/sp07122005.shtml
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Sun, Jul 24, 2005 at 01:49:25PM -0700, Michael G Schwern wrote: > 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". Cool. I apologize for complaining about the parts that were already there. Ronald
Re: perlfunc sez crypt() encrypts... but it doesn't.
How about using the word "obfuscate?" It's a nice word -- David L Nicol I've got your Oz right here http://cronos.advenge.com/pc/oz/TOC.html
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sun, Jul 24, 2005 at 08:57:52PM -0400, John E. Malmberg wrote: > 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. 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. Otherwise just keep a clean copy of the source code around to diff against. Disk is cheap. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <[EMAIL PROTECTED]>
NaN on platforms that don't support it
Hi, use warnings; $x = "NaN"; $x += 1; $y = "foo"; $y += 1; print $x, " ", $y, "\n"; __END__ For me, produces: Argument "foo" isn't numeric in addition (+) at try.pl line 7. 1 1 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. I also checked by running (as suggested in perlop): perl -le '$a = NaN; print "No NaN support here" if $a == $a' So . given that IEEE NaN is not supported, shouldn't "NaN" be treated the same as any other string - in which case the above sample script would produce the additional warning: Argument "NaN" isn't numeric in addition (+) at try.pl line 4. The fact that '$x += 1;' produces no warning implies to me that NaN is being understood and treated correctly - but that's not the case. I think the identical situation arises with INF. (This post is a result of the more-or-less current c.l.p.misc thread "IEEE NaN screwed up?") Cheers, Rob
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
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/ -- 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
Re: [PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sun, Jul 24, 2005 at 05:47:26PM -0500, Craig A. Berry wrote: > And this should take care of it. Accidentally left out of my patch of two > hours ago. Thanks applied (25218) Nicholas Clark
Re: [PATCH] blead help for VMS
Op een mooie zomerdag (Sunday 24 July 2005 23:21),schreef Nicholas Clark: > On Sun, Jul 24, 2005 at 03:31:55PM -0500, Craig A. Berry wrote: > > 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 [snip p4 stuff] > Thanks, applied (25217) I am sorry to say we're not quite there yet :-( This in on the VAX (OpenVMS V7.2): CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj/NoList/ FLOAT=G_FLOAT/Define=PERL_CORE GLOBALS.C */ %VCG-W-BADPSECT, The program section(psect) specified by this statement has conflicting 'nowrite' attributes with another definition of the same program section. At line number 65 in DISK$USER_2: [TIMMERMAN.KLAD.PERL-CURRENT]GLOBALS.C;1. %VCG-I-SUMMARY, Completed with 0 error(s), 1 warning(s), and 0 informational messages. At line number 65 in DISK$USER_2: [TIMMERMAN.KLAD.PERL-CURRENT]GLOBALS.C;1. %MMK-F-ERRUPD, error status %X10B9 occurred when updating target GLOBALS.OBJ TIMMERMAN:FAFNER$ cc/version Compaq C V6.4-005 on OpenVMS VAX V7.2 and on Alpha (OpenVMS V8.2): 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 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 1845 in file USER1:[ABELTJE.PERL-CURRENT]DOIO.C;1 %MMS-F-ABORT, For target DOIO.OBJ, CLI returned abort status: %X10B91260. $ cc/version Compaq C V6.5-001 on OpenVMS Alpha V8.2 Good luck, Abe -- Unspecified = it may work or it may not or demons may fly out of your nose. And the hairyness of the demons is almost guaranteed to vary from platform to platform. -- Jarkko Hietaniemi on p5p @ 2001-12-10
[PATCH] Re: [EMAIL PROTECTED] on OpenVMS (not good)
At 5:48 PM -0400 7/24/05, John E. Malmberg wrote:
>>
>>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.
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))
tot--;
}
else { /* don't let root wipe out directories without -U */
if (PerlLIO_lstat(s,&PL_statbuf) < 0 ||
S_ISDIR(PL_statbuf.st_mode))
tot--;
else {
- if (UNLINK(s))
+ if (UNLINK((char *)s))
tot--;
}
}
[end of patch]
--
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Re: [PATCH] blead help for VMS
On Sun, Jul 24, 2005 at 03:31:55PM -0500, Craig A. Berry wrote: > 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 $ p4 help rename rename -- How to rename files p4 integrate from to p4 delete from p4 submit Perforce does not support a single 'rename' command, but files can be renamed by branching one file into another and then deleting the original file. The 'from' and 'to' file arguments may include wildcards as long as they are matched. Integrating from files require read access to the files, but deleting them requires write access. For further information, see the help for the individual commands. And what it doesn't state explicitly is that you're renaming files, not directories, so you then have to use perforce wildcards, ie: $ cd ext/Compress/Zlib/ $ p4 integrate zlib-src-1.2.3/... zlib-src/... $ p4 delete zlib-src-1.2.3/... Thanks, applied (25217) Nicholas Clark
Re: Building with a precompiled header -- solved
On Jul 22, 2005, at 7:08 AM, Joshua Juran wrote: I'm trying to build perl (5.6.1) with a precompiled header. The problem I'm having is that a precompiled header assumes a static header context for all source files, whereas the perl source files 'customize' the headers by defining relevant macros prior to including them. I was able to work around the PERL_IN_foo_C differences by defining PERL_DECL_PROT. I also added "#define PERLIO_NOT_STDIO 0" to avoid a macro redefinition in perlio.c.But linking failed because the interpreter globals were all undefined. Problem solved -- I now compile globals.c separately from the other sources. Precompiling the header results in MUCH faster compiling -- by at least a factor of ten with Metrowerks CodeWarrior. Only a slight exaggeration. I ran a test (prior to my solution above), and building miniperl with the header precompiled (though failing to link) took 4 minutes 35 seconds (including precompiling), whereas building without took 40 minutes 49 seconds. So it's actually a factor of nine -- building from scratch, that is. Recompiling a source file or several (with headers unmodified) would be a great deal faster than that. Josh -- Joshua Juran Metamage Software Creations - Mac Software and Consulting http://www.metamage.com/ * Creation at the highest state of the art *
Re: [PATCH] blead help for VMS
On Sun, Jul 24, 2005 at 03:31:55PM -0500, Craig A. Berry wrote: > 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. It'll also make version history spelunking a lot easier to not have the directory name changing all the time. -- 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
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
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. 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". -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Just call me 'Moron Sugar'. http://www.somethingpositive.net/sp05182002.shtml --- pod/perlfunc.pod2005/07/24 02:57:16 1.2 +++ pod/perlfunc.pod2005/07/24 20:39:44 @@ -885,31 +885,35 @@ =item crypt PLAINTEXT,SALT -Digests a string exactly like the crypt(3) function in the C library -(assuming that you actually have a version there that has not been -extirpated as a potential munition). +Creates a digest string exactly like the crypt(3) function in the C +library (assuming that you actually have a version there that has not +been extirpated as a potential munition). crypt() is a one-way hash function. The PLAINTEXT and SALT is turned -into a short, fixed length string, called a digest, which is returned. -The same PLAINTEXT and SALT will always return the same string, but -there is no (known) way to get the original PLAINTEXT from the hash. -The SALT is visible as part of the digest. Small changes in the -PLAINTEXT will result in large changes in the hash. +into a short string, called a digest, which is returned. The same +PLAINTEXT and SALT will always return the same string, but there is no +(known) way to get the original PLAINTEXT from the hash. Small +changes in the PLAINTEXT or SALT will result in large changes in the +digest. There is no decrypt function. This function isn't all that useful for -cryptography (for that, see your nearby CPAN mirror) and the name -"crypt" is a bit of a misnomer. Instead it is primarily used to check -if two pieces of text are the same without having to transmit or store -the text itself. An example is checking if a correct password is -given. The digest of the password is stored, not the password itself. -The user types in a password which is crypt()'d with the same salt as -the stored digest. If the two digests match the password is correct. +cryptography (for that, look for F modules on your nearby CPAN +mirror) and the name "crypt" is a bit of a misnomer. Instead it is +primarily used to check if two pieces of text are the same without +having to transmit or store the text itself. An example is checking +if a correct password is given. The digest of the password is stored, +not the password itself. The user types in a password which is +crypt()'d with the same salt as the stored
[PATCH] blead help for VMS
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.
--- MANIFEST;-0 Thu Jul 21 08:09:42 2005
+++ MANIFESTSat Jul 23 18:54:48 2005
@@ -170,28 +170,28 @@ ext/Compress/Zlib/t/04encoding.t Compres
ext/Compress/Zlib/t/05gzsetp.t Compress::Zlib
ext/Compress/Zlib/t/06gzdopen.tCompress::Zlib
ext/Compress/Zlib/typemap Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/adler32.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/compress.cCompress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/crc32.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/crc32.h Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/deflate.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/deflate.h Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/gzio.cCompress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/infback.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inffast.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inffast.h Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inffixed.hCompress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inflate.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inflate.h Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inftrees.cCompress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/inftrees.hCompress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/trees.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/trees.h Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/uncompr.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/zconf.h Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/zlib.hCompress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/zutil.c Compress::Zlib
-ext/Compress/Zlib/zlib-src-1.2.3/zutil.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/adler32.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/compress.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/crc32.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/crc32.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/deflate.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/deflate.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/gzio.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/infback.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/inffast.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/inffast.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/inffixed.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/inflate.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/inflate.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/inftrees.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/inftrees.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/trees.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/trees.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/uncompr.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/zconf.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/zlib.h Compress::Zlib
+ext/Compress/Zlib/zlib-src/zutil.c Compress::Zlib
+ext/Compress/Zlib/zlib-src/zutil.h Compress::Zlib
ext/Data/Dumper/ChangesData pretty printer, changelog
ext/Data/Dumper/Dumper.pm Data pretty printer, module
ext/Data/Dumper/Dumper.xs Data pretty printer, externals
--- mg.c;-0 Thu Jul 21 11:10:07 2005
+++ mg.cSat Jul 23 22:08:49 2005
@@ -1045,7 +1045,7 @@ Perl_magic_setenv(pTHX_ SV *sv, MAGIC *m
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 = (char *) s;
Stat_t sbuf;
int i = 0, j = 0;
--- pp_ctl.c;-0 Sun Jul 17 19:46:43 2005
+++ pp_ctl.cSat Jul 23 22:50:32 2005
@@ -3143,7 +3143,7 @@ PP(pp_require)
I32 i;
#ifdef VMS
char *unixname;
- if ((unixname = tounixspec(name, Nullch)) != Nullch)
+ if ((unixname = tounixspec((char *)name, Nullch)) != Nullch)
#endif
{
namesv = NEWSV(806, 0);
@@ -3280,7 +3280,7 @@ PP(pp_require)
#else
# ifdef VMS
char *unixdir;
- if ((unixdir = tounixpath(dir, Nullch)) == Nullch)
+ if ((unixdir = tounixpath((char *)dir, Nullch)) == Nullch)
continue;
sv_setpv(namesv, unixdir);
sv_catpv(namesv, unixname);
--- pp_sys.c;-0 Wed Jul 20 07:58:35 2005
+++ pp_sys.cSat Jul 23 22:12:35 2005
@@ -3607,7 +3607,7 @@ PP(pp_chdir)
#endif
}
else
-
Re: What's holding up mainperl from upgrading MakeMaker?
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? > I'm testing a patch against blead that should get it building again. -- 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: perlfunc sez crypt() encrypts... but it doesn't.
On Sun, Jul 24, 2005 at 12:59:06PM +0200, Rafael Garcia-Suarez wrote: > On 7/24/05, Michael G Schwern <[EMAIL PROTECTED]> wrote: > > > More importantly for the purposes of documentation, at least on my system, > > > I see this: > > > > Just because someone else does something poorly doesn't mean we have to, > > too. > > perlfunc says : > > =item crypt PLAINTEXT,SALT > > Encrypts a string exactly like the crypt(3) function in the C library > > And the C function is a wrapper around the libc function. That's one > of the many C/UNIX legacies that are present in the perl core... I'm not sure I understand. Nobody's saying that crypt() isn't or shouldn't be a wrapper around crypt(3) or that its behavior should change, just that we don't have to parrot their documentation inadequacies. -- 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: 'no strict "refs"' considered harmful?
On Jul 24, Tassilo von Parseval said:
On Sun, Jul 24, 2005 at 02:44:12AM -0400 Jeff 'japhy' Pinyan wrote:
for (...) {
my $code = sub { ... };
no strict 'refs';
*$_ = $code;
}
for (...) {
no strict 'refs';
*$_ = sub {
use strict;
...
};
}
There's also the somewhat ugly:
for (...) {
*{; no strict 'refs'; \*$_ } = sub { ... };
}
I think it's awfully obfuscated, though. Yes, I could see it being
written this way:
for (...) {
*{;
no strict 'refs';
\*$_} = sub { ... };
}
and driving people to madness.
--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
http://japhy.perlmonk.org/ % have long ago been overpaid?
http://www.perlmonks.org/ %-- Meister Eckhart
Re: 'no strict "refs"' considered harmful?
How about
use strict;
sub unstrict : lvalue
{
my $sym = shift;
no strict 'refs';
${$sym};
}
unstrict("a::b") = 1;
print "$a::b\n";
F
On 7/24/05, Tassilo von Parseval <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 24, 2005 at 02:44:12AM -0400 Jeff 'japhy' Pinyan wrote:
> > That sounds sillier than my concern actually is. I noticed today (I don't
> > know why today, and not the days before when I've seen this common idiom)
> > that a person creating dynamic functions did the following:
> >
> > use strict;
> >
> > # ...
> >
> > for (@function_names) {
> > no strict 'refs';
> > *$_ = sub {
> > # ...
> > };
> > }
> >
> > I've seen that in various perldocs, and it seems to be a common practice
> > when it comes to defining dynamically named functions. But there's a very
> > specific flaw inherent here.
> >
> > use strict;
> >
> > my @method_names = qw( foobar quux xyzzy );
> >
> > for my $m (@method_names) {
> > no strict 'refs';
> > *{ "ClassName::$m" } = sub {
> > my ($self, $val) = @_;
> > $self->{$m} = $val;
> > };
> > }
> >
> > This sets up a bunch of methods for some object of class ClassName. The
> > idea being you can now say
> >
> > my $obj = ClassName->new;
> > $obj->foobar(10);
> >
> > and set $obj->{foobar} to 10. But what if you slip up and write
> >
> > ClassName->foobar(10);
> >
> > As Scooby-Doo would say, "RUH ROH!" We turned off strict's grip on
> > references, and now we've accidentally worked with a symbolic reference.
> > And strict won't mind a bit!
>
> Nice catch. It looks obvious enough, but yet it never occured to me. For
> more complicated methods generated thusly, you can now even mistype
> lexicals and no longer receive the compile-time error.
>
> > Although it looks a bit clunkier, I would suggest changing the idiom to
> >
> > for (...) {
> > my $code = sub { ... };
> > no strict 'refs';
> > *$_ = $code;
> > }
>
> Or:
>
> for (...) {
> no strict 'refs';
> *$_ = sub {
> use strict;
> ...
> };
> }
>
> which avoids the temporary '$code'. Also, careless authors might feel
> tempted to 'optimize' your code again into its original strictless form.
>
> Tassilo
> --
> use bigint;
> $n=71423350343770280161397026330337371139054411854220053437565440;
> $m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
>
>
Re: [EMAIL PROTECTED] on OpenVMS (not good)
Nicholas Clark wrote: On Sat, Jul 23, 2005 at 03:36:39PM -0400, John E. Malmberg wrote: How do I reproduce this? I pulled down perl-5.9.2 and started a build and it fails with: CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/List #$d_sitecustomize USE_SITECUSTOMIZE /**/ .^ %CC-W-BADDIRECTIVE, "$d_sitecustomize" is an invalid preprocessor directive, an at line number 3462 in file PERL_BUILD_ROOT:[00]config.h;1 %MMK-F-ERRUPD, error status %X10B91260 occurred when updating target MINIPERLMA 23-JUL-2005 15:28:53 The perl 5.9.2 release is now somewhat out of date. That bug has been fixed. And new ones introduced instead :-( The best way to get the current source is with rsync. The master source repository is in perforce, and there isn't anonymous access to that. We don't tend to make snapshots, I think partly because everyone actively developing is very happy with rsync, and partly because snapshots seem to generate near zero feedback, suggesting the time is better spent elsewhere. (I suspect that the widespread use of rsync helps explain the lack of interest in specific snapshots. In effect every commit gets treated like a snapshot) There are a few paragraphs on what can be got with rsync in perlhack.pod: http://search.cpan.org/~rgarcia/perl-5.9.2/pod/perlhack.pod#Keeping_in_sync but most simply if you run rsync -avz rsync://ftp.linux.activestate.com/perl-current/ perl/ I suppose it would be simple if I had a stable rsync to run. However rsync source as supplied depends on one of those fork() things to work. Well I will try my experimental prototype threaded version rsync. If I run it enough times, it usually will get the stuff. I also may have to delete some corrupted files. Is the stuff in porting/.*.* important? It seems I have a bug in mkstemp() to work around, nothing in that directory with a leading "." transfered. Aside from that, the first pass got me to: xsutils.c %SYSTEM-F-STKOVF, stack overflow, PC=810AD3C4, PS=001B Subsequent passes hang at Changes5.6. Maybe I got enough to do a build. The copy of rsync source that I am using rsync to pull down is now clean compiling, but I have to implement the POSIX thread synchronization code before it will be usable. -John [EMAIL PROTECTED] Personal Opinion Only
[perl #36645] INSTALLATION OF PERL 5.8.7
# New Ticket Created by "Brezovec, Dick" # Please include the string: [perl #36645] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36645 > > I attempted to install Perl 5.8.7 by using the command: > > # Configure > > Below is the results of using this command: > What shall I do now?? > > This installation shell script will examine your system and ask you questions > to determine how the perl5 package should be installed. If you get > stuck on a question, you may use a ! shell escape to start a subshell or > execute a command. Many of the questions will have default answers in square > brackets; typing carriage return will give you the default. > > On some of the questions which ask for file or directory names you are allowed > to use the ~name construct to specify the login directory belonging to "name", > even if you don't have a shell which knows about that. Questions where this > is > allowed will be marked "(~name ok)". > > [Type carriage return to continue] > > The prompter used in this script allows you to use shell variables and > backticks in your answers. You may use $1, $2, etc... to refer to the words > in the default answer, as if the default line was a set of arguments given to > a > script shell. This means you may also use $* to repeat the whole default > line, > so you do not have to re-type everything to add something to the default. > > Everytime there is a substitution, you will have to confirm. If there is an > error (e.g. an unmatched backtick), the default answer will remain unchanged > and you will be prompted again. > > If you are in a hurry, you may run 'Configure -d'. This will bypass nearly > all > the questions and use the computed defaults (or the previous answers if there > was already a config.sh file). Type 'Configure -h' for a list of options. > You may also start interactively and then answer '& -d' at any prompt to turn > on the non-interactive behaviour for the remainder of the execution. > > [Type carriage return to continue] > > Much effort has been expended to ensure that this shell script will run on any > Unix system. If despite that it blows up on yours, your best bet is to edit > Configure and run it again. If you can't run Configure for some reason, > you'll have to generate a config.sh file by hand. Whatever problems you > have, let me ([EMAIL PROTECTED]) know how I blew it. > > This installation script affects things in two ways: > > 1) it may do direct variable substitutions on some of the files included >in this kit. > 2) it builds a config.h file for inclusion in C programs. You may edit >any of these files as the need arises after running this script. > > If you make a mistake on a question, there is no easy way to back up to it > currently. The easiest thing to do is to edit config.sh and rerun all the SH > files. Configure will offer to let you do this before it runs the SH files. > > [Type carriage return to continue] > > Locating common programs... > awk is in /usr/bin/awk. > cat is in /usr/bin/cat. > chmod is in /usr/bin/chmod. > comm is in /usr/bin/comm. > cp is in /usr/bin/cp. > echo is in /usr/bin/echo. > expr is in /usr/bin/expr. > grep is in /usr/bin/grep. > ls is in /usr/bin/ls. > mkdir is in /usr/bin/mkdir. > rm is in /usr/bin/rm. > sed is in /usr/bin/sed. > sort is in /usr/bin/sort. > touch is in /usr/bin/touch. > tr is in /usr/bin/tr. > uniq is in /usr/bin/uniq. > > Don't worry if any of the following aren't found... > I don't see Mcc out there, offhand. > ar is in /usr/ccs/bin/ar. > I don't see bison out there, either. > I don't see byacc out there, either. > cpp is in /usr/lib/cpp. > csh is in /usr/bin/csh. > date is in /usr/bin/date. > egrep is in /usr/bin/egrep. > gmake is in /cots/util/bin/gmake. > gzip is in /cots/util/bin/gzip. > less is in /cots/util/bin/less. > ln is in /usr/bin/ln. > make is in /usr/ccs/bin/make. > more is in /usr/bin/more. > nm is in /usr/ccs/bin/nm. > nroff is in /usr/bin/nroff. > pg is in /usr/bin/pg. > test is in /usr/bin/test. > uname is in /usr/bin/uname. > zip is in /usr/bin/zip.> > Using the test built into your sh. > > Checking compatibility between /usr/bin/echo and builtin echo (if any)... > They are compatible. In fact, they may be identical. > > Symbolic links are supported. > > Checking how to test for symbolic links... > You can test for symbolic links with 'test -h'. > > > Good, your tr supports [:lower:] and [:upper:] to convert case. > Using [:upper:] and [:lower:] to convert case. > > First time through, eh? I have some defaults handy for some systems > that need some extra help getting the Configure answers right: > > 3b1 dos_djgpp irix_6_0nonstopux sunos_4_0 > aix dynix irix_6_1openbsd sunos_4_1 > aix_3 dynixptxisc opussuper-ux > aix_4 epix
Re: [PATCH perlfunc.pod/crypt] crypt() digests, not encrypts
On Sat, Jul 23, 2005 at 05:25:18PM -0700, Michael G Schwern wrote: > Attached is a patch which replaces the term "encrypt" in the perlfunc/crypt > documentation with "digest" or "hash" which more accurately describes what > crypt does. I also added in some better explaination of what crypt does and > what one-way hashing is useful for. > > I tried to avoid "hash" where possible to avoid confusion with the hash > data structure. Even though they are related it would just confuse things. > > Below is the new documentation after patching. 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. 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.) 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. The second paragraph in the existing documentation seems to explain the issue clearly anyway. Ronald
Re: What's holding up mainperl from upgrading MakeMaker?
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. I'm testing a patch against blead that should get it building again. -- Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
Re: Smoke [5.9.3] 25216 FAIL(M) linux 2.4.23-sparc-r1 [gentoo] (sparc64/1 cpu)
Op een mooie zomerdag (Sunday 24 July 2005 19:07),schreef Abe Timmerman: > Automated smoke report for 5.9.3 patch 25216 > h: TI UltraSparc I (SpitFire) (143MHz) (sparc64/1 cpu) > onlinux - 2.4.23-sparc-r1 [gentoo] > using cc version 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r2, > propolice) smoketime 1 day 7 hours 49 minutes (average 1 hour 59 minutes) > > Summary: FAIL(M) > > 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 > >25216 Configuration (common) none > --- - > M - - M - - From the smokelog: make: [extra.pods] Error 1 (ignored) make: *** [lib/Config.pod] Bus error make: *** Deleting file `lib/Config.pod' Unable to make anything but miniperl in this configuration TSTENV = minitest cp ext/re/re.pm ext/re/re.tmp && sh mv-if-diff ext/re/ re.tmp lib/re.pm make[1]: *** [lib/Config.pod] Bus error make[1]: *** Deleting file `lib/Config.pod' make: [minitest.prep] Error 2 (ignored) You may see some irrelevant test failures if you have been unable to build lib/Config.pm, lib/lib.pm or the Unicode data files. && ./perl TEST -minitest base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/ *.t uni/*.t > Over to you, Jarkko ??? Jarkko> Urque. Hmm... I can't seem to find a patch in there anywhere. -- Nicholas Clark on p5p @ 2004-01-23
Re: [EMAIL PROTECTED] on OpenVMS (not good)
Op een mooie zomerdag (Sunday 24 July 2005 14:18),schreef John E. Malmberg: > Nicholas Clark wrote: ... > > The best way to get the current source is with rsync. The master source > > repository is in perforce, and there isn't anonymous access to that. > > We don't tend to make snapshots, I think partly because everyone actively > > developing is very happy with rsync, and partly because snapshots seem to > > generate near zero feedback, suggesting the time is better spent > > elsewhere. (I suspect that the widespread use of rsync helps explain the > > lack of interest in specific snapshots. In effect every commit gets > > treated like a snapshot) > > > > There are a few paragraphs on what can be got with rsync in perlhack.pod: > > > > http://search.cpan.org/~rgarcia/perl-5.9.2/pod/perlhack.pod#Keeping_in_sy > >nc > > > > but most simply if you run > > > > rsync -avz rsync://ftp.linux.activestate.com/perl-current/ perl/ > > I suppose it would be simple if I had a stable rsync to run. However > rsync source as supplied depends on one of those fork() things to work. Another option is to install the Test::Smoke module from CPAN and configure it to use FTP so you can use the synctree.pl script to sync the perl source-tree(s). Contact me directly (on my cpan.org e-mailaddress) if you need any help with that. Good luck, Abe -- I think this requires more thought, therefore I'm excising the "promise" from perldelta and replacing it with more non-committal mumbling. -- Jarkko Hietaniemi on p5p @ 2002-05-27
Re: perlfunc sez crypt() encrypts... but it doesn't.
On 7/24/05, Michael G Schwern <[EMAIL PROTECTED]> wrote: > > More importantly for the purposes of documentation, at least on my system, > > I see this: > > Just because someone else does something poorly doesn't mean we have to, too. perlfunc says : =item crypt PLAINTEXT,SALT Encrypts a string exactly like the crypt(3) function in the C library And the C function is a wrapper around the libc function. That's one of the many C/UNIX legacies that are present in the perl core...
[PATCH] perlfunc.pod: s/definetely/definitely/
I googled "definetely" and it seems to be widely used. But I found this: http://wikitravel.org/en/Wikitravel:List_of_common_misspellings --- 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
Re: [EMAIL PROTECTED] on OpenVMS (not good)
On Sat, Jul 23, 2005 at 03:36:39PM -0400, John E. Malmberg wrote: > How do I reproduce this? > > I pulled down perl-5.9.2 and started a build and it fails with: > > CC/DECC/NOANSI_ALIAS > /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/List > > #$d_sitecustomize USE_SITECUSTOMIZE /**/ > .^ > %CC-W-BADDIRECTIVE, "$d_sitecustomize" is an invalid preprocessor > directive, an > at line number 3462 in file PERL_BUILD_ROOT:[00]config.h;1 > %MMK-F-ERRUPD, error status %X10B91260 occurred when updating target > MINIPERLMA > 23-JUL-2005 15:28:53 The perl 5.9.2 release is now somewhat out of date. That bug has been fixed. And new ones introduced instead :-( The best way to get the current source is with rsync. The master source repository is in perforce, and there isn't anonymous access to that. We don't tend to make snapshots, I think partly because everyone actively developing is very happy with rsync, and partly because snapshots seem to generate near zero feedback, suggesting the time is better spent elsewhere. (I suspect that the widespread use of rsync helps explain the lack of interest in specific snapshots. In effect every commit gets treated like a snapshot) There are a few paragraphs on what can be got with rsync in perlhack.pod: http://search.cpan.org/~rgarcia/perl-5.9.2/pod/perlhack.pod#Keeping_in_sync but most simply if you run rsync -avz rsync://ftp.linux.activestate.com/perl-current/ perl/ you will get a local directory perl/ containing the current development sources. If you build that you should see the same problems as Abe is reporting. Nicholas Clark
Re: [PATCH] perlfunc.pod
> > [...] I wanted to clarify that do {}
> > isn't special for "for"/"foreach" modifiers
> > (they are loop modifiers, aren't they?).
>
> Good point. I guess they are.
>
--- perl-current/pod/perlfunc.pod Sun Jul 24 11:30:36 2005
+++ perl-patched/pod/perlfunc.pod Sun Jul 24 11:38:16 2005
@@ -1220,8 +1220,8 @@
=item do BLOCK
Not really a function. Returns the value of the last command in the
-sequence of commands indicated by BLOCK. When modified by a loop
-modifier, executes the BLOCK once before testing the loop condition.
+sequence of commands indicated by BLOCK. When modified by C or C
+loop modifier, executes the BLOCK once before testing the loop condition.
(On other statements the loop modifiers test the conditional first.)
C does I count as a loop, so the loop control statements
Re: [EMAIL PROTECTED] on OpenVMS (not good)
How do I reproduce this? I pulled down perl-5.9.2 and started a build and it fails with: CC/DECC/NOANSI_ALIAS /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj/List #$d_sitecustomize USE_SITECUSTOMIZE /**/ .^ %CC-W-BADDIRECTIVE, "$d_sitecustomize" is an invalid preprocessor directive, an at line number 3462 in file PERL_BUILD_ROOT:[00]config.h;1 %MMK-F-ERRUPD, error status %X10B91260 occurred when updating target MINIPERLMA 23-JUL-2005 15:28:53 -John [EMAIL PROTECTED] Personal Opinion Only
Re: [EMAIL PROTECTED] on OpenVMS (not good)
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 means that the routine that the macro UNLINK is eventually defined as pointing to is missing a const qualifier on it's argument. Finding out exactly what it is not happy about looks like it will require a listing that expands macro expansions, and possibly one that shows the contents of the include files. The CRTL unlink() call has the const qualifier as required by X/OPEN. -John [EMAIL PROTECTED] Personal Opinion Only
Re: 'no strict "refs"' considered harmful?
On Sun, Jul 24, 2005 at 02:44:12AM -0400 Jeff 'japhy' Pinyan wrote:
> That sounds sillier than my concern actually is. I noticed today (I don't
> know why today, and not the days before when I've seen this common idiom)
> that a person creating dynamic functions did the following:
>
> use strict;
>
> # ...
>
> for (@function_names) {
> no strict 'refs';
> *$_ = sub {
> # ...
> };
> }
>
> I've seen that in various perldocs, and it seems to be a common practice
> when it comes to defining dynamically named functions. But there's a very
> specific flaw inherent here.
>
> use strict;
>
> my @method_names = qw( foobar quux xyzzy );
>
> for my $m (@method_names) {
> no strict 'refs';
> *{ "ClassName::$m" } = sub {
> my ($self, $val) = @_;
> $self->{$m} = $val;
> };
> }
>
> This sets up a bunch of methods for some object of class ClassName. The
> idea being you can now say
>
> my $obj = ClassName->new;
> $obj->foobar(10);
>
> and set $obj->{foobar} to 10. But what if you slip up and write
>
> ClassName->foobar(10);
>
> As Scooby-Doo would say, "RUH ROH!" We turned off strict's grip on
> references, and now we've accidentally worked with a symbolic reference.
> And strict won't mind a bit!
Nice catch. It looks obvious enough, but yet it never occured to me. For
more complicated methods generated thusly, you can now even mistype
lexicals and no longer receive the compile-time error.
> Although it looks a bit clunkier, I would suggest changing the idiom to
>
> for (...) {
> my $code = sub { ... };
> no strict 'refs';
> *$_ = $code;
> }
Or:
for (...) {
no strict 'refs';
*$_ = sub {
use strict;
...
};
}
which avoids the temporary '$code'. Also, careless authors might feel
tempted to 'optimize' your code again into its original strictless form.
Tassilo
--
use bigint;
$n=71423350343770280161397026330337371139054411854220053437565440;
$m=-8,;;$_=$n&(0xff)<<$m,,$_>>=$m,,print+chr,,while(($m+=8)<=200);
