[inseparable changes from patch from perl5.003_08 to perl5.003_09]

 CORE LANGUAGE CHANGES

Subject: Lexical locales
From: Chip Salzenberg <chip@atlantic.net>
Files: too many to list

    make effectiveness of locales depend on C<use locale>

Subject: Lexical scoping cleanup
From: Chip Salzenberg <chip@atlantic.net>
Files: many... but mostly perly.y and toke.c

    tighten scoping of lexical variables, somewhat on the
    new constructs and somewhat on the old

Subject: memory corruption / security bug in sysread,syswrite + patch
Date: Mon, 25 Nov 1996 21:46:31 +0200 (EET)
From: Jarkko Hietaniemi <jhi@cc.hut.fi>
Files: MANIFEST pod/perldiag.pod pod/perlfunc.pod pp_sys.c t/op/sysio.t
Msg-ID: <199611251946.VAA30459@alpha.hut.fi>

    (applied based on p5p patch as commit d7090df90a9cb89c83787d916e40d92a616b146d)

 DOCUMENTATION

Subject: perldiag documentation patch.
Date: Wed, 20 Nov 96 16:07:28 GMT
From: Paul Marquess <pmarquess@bfsec.bt.co.uk>
Files: pod/perldiag.pod

    private-msgid: <9611201607.AA12729@claudius.bfsec.bt.co.uk>

Subject: a missing perldiag entry
Date: Thu, 21 Nov 1996 15:24:02 -0500
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: pod/perldiag.pod

    private-msgid: <199611212024.PAA15758@aatma.engin.umich.edu>

Subject: perlfunc patch
Date: Wed, 20 Nov 96 14:04:08 GMT
From: Paul Marquess <pmarquess@bfsec.bt.co.uk>
Files: pod/perlfunc.pod

    Following on from the patch to make uc, lc etc default to $_ (as per
    Camel II), here is a followup patch to perlfunc that documents the
    change. I think I have documented all the other cases where $_
    defaulting works as well.
    
    p5p-msgid: <9611201404.AA12477@claudius.bfsec.bt.co.uk>

 OTHER CORE CHANGES

Subject: Properly prototype safe{malloc,calloc,realloc,free}.
From: Chip Salzenberg <chip@atlantic.net>
Files: proto.h

Subject: UnixWare 2.1 fix for perl5.003_08 - cope with fp->_cnt < -1, allow debugging
Date: Wed, 20 Nov 1996 14:27:06 +0100
From: John Hughes <john@AtlanTech.COM>
Files: sv.c

    UnixWare 2.1 has no fp->_base so most of the debugging stuff in sv_gets just
    core dumps.
    
    Also, for some unknown reason fp->_cnt is sometimes < -1, screwing up the
    initial SvGROW in svgets.
    
    Appart from that its io is std.
    
    p5p-msgid: <01BBD6EE.E915C860@malvinas.AtlanTech.COM>

Subject: die -> croak
Date: Thu, 21 Nov 1996 16:11:21 -0500
From: Gurusamy Sarathy <gsar@engin.umich.edu>
Files: pp_ctl.c

    private-msgid: <199611212111.QAA17070@aatma.engin.umich.edu>

Subject: Cleanup of {,un}pack('w').
From: Chip Salzenberg <chip@atlantic.net>
Files: pp.c

Subject: Cleanups from Ilya.
From: Chip Salzenberg <chip@atlantic.net>
Files: gv.c malloc.c pod/perlguts.pod pp_ctl.c

Subject: Fix for unpack('w') on 64-bit systems.
From: Chip Salzenberg <chip@atlantic.net>
Files: pp.c

Subject: Re: LC_NUMERIC support is ready + performance
Date: Mon, 25 Nov 1996 22:08:27 -0500 (EST)
From: Ilya Zakharevich <ilya@math.ohio-state.edu>
Files: sv.c

    Chip Salzenberg writes:
    > 
    > Having thought about the use of our own gcvt() and atof(), I've run
    > away in horror.  It's just too hairy.
    > 
    > So I've implemented the only viable alternative I know of: Toggling
    > LC_NUMERIC to/from "C" as needed.
    > 
    > Patch follows.
    > 
    > I think _09 is *very* close.
    
    Since _09 is going to be alpha anyway, I reiterate my question:
    	Is there any reason to not include my hash/array performance
    		patches in _09?
    
    Btw, here is the next performance patch. It makes PADTMP values
    stealable too. I do not do by setting TEMP flags on them, since it
    would be a very distributed patch, and it would break some places
    which check for TEMP for some other reasons (yes, I checked ;-).
    
    This patch decreases *twice* the memory usage of
    	perl -e '$a = "a" x 1e6; 1'
    
    Enjoy,
    
    p5p-msgid: <199611260308.WAA02677@monk.mps.ohio-state.edu>

Subject: Hash key sharing improvements from Ilya.
From: Chip Salzenberg <chip@atlantic.net>
Files: hv.c hv.h proto.h

Subject: Mortal stack pre-allocation from Ilya.
From: Chip Salzenberg <chip@atlantic.net>
Files: pp.c pp.h pp_ctl.c pp_hot.c pp_sys.c

 PORTABILITY

Subject: VMS patches post-5.003_08
Date: Fri, 22 Nov 1996 18:16:31 -0500 (EST)
From: Charles Bailey <bailey@hmivax.humgen.upenn.edu>
Files: lib/ExtUtils/MM_Unix.pm lib/ExtUtils/MM_VMS.pm lib/ExtUtils/MakeMaker.pm lib/File/Path.pm mg.c pp_ctl.c utils/h2xs.PL vms/config.vms vms/descrip.mms vms/gen_shrfls.pl vms/genconfig.pl vms/perlvms.pod vms/vms.c vms/vmsish.h

    Here're diffs to bring a base 5.003_08 up to the current VMS working
    sources.  Nearly all of the changes are VMS-specific, and comprise
    miscellaneous bugfixes accumulated since 5.003_07, rather than any
    particular problem with 5.003_08.  I'm posting them here since some
    of the patches change core files, and I'd like to insure that I
    haven't accidentally created problems for anyone else.
    
    With these and a couple of of the small patches already send to p5p,
    5.003_08 builds clean and passes all tests under VMS.
    
    Thanks, Chip, for all the work.
    
    p5p-msgid: <1996Nov22.181631.1603238@hmivax.humgen.upenn.edu>

1 files changed, 30 insertions, 18 deletions

diff --git a/hv.h b/hv.h
index 5c41309f00..746e4286c1 100644
--- a/hv.h
+++ b/hv.h
@@ -8,13 +8,18 @@
  */
 
 typedef struct he HE;
+typedef struct he_key HEK;
 
 struct he {
     HE		*hent_next;
-    char	*hent_key;
+    HEK		*hent_hk;
     SV		*hent_val;
-    U32		hent_hash;
-    I32		hent_klen;
+};
+
+struct he_key {
+    U32		hk_hash;
+    I32		hk_len;
+    char	hk_key[1];
 };
 
 struct xpvhv {
@@ -84,20 +89,27 @@ struct xpvhv {
 
 #define Nullhe Null(HE*)
 #define HeNEXT(he)		(he)->hent_next
-#define HeKEY(he)		(he)->hent_key
-#define HeKLEN(he)		(he)->hent_klen
+#define HeKEY_hk(he)		(he)->hent_hk
+#define HeKEY(he)		HK_KEY(HeKEY_hk(he))
+#define HeKEY_sv(he)		(*(SV**)HeKEY(he))
+#define HeKLEN(he)		HK_LEN(HeKEY_hk(he))
 #define HeVAL(he)		(he)->hent_val
-#define HeHASH(he)		(he)->hent_hash
-#define HePV(he)		((he)->hent_klen == HEf_SVKEY) ?		\
-				SvPV((SV*)((he)->hent_key),na) :		\
-				(he)->hent_key))
-#define HeSVKEY(he)		(((he)->hent_key && 				\
-				  (he)->hent_klen == HEf_SVKEY) ?		\
-				 (SV*)((he)->hent_key) : Nullsv)
-
-#define HeSVKEY_force(he)	((he)->hent_key ?				\
-				 (((he)->hent_klen == HEf_SVKEY) ?		\
-				  (SV*)((he)->hent_key) :			\
-				  sv_2mortal(newSVpv((he)->hent_key,		\
-						     (he)->hent_klen))) :	\
+#define HeHASH(he)		HK_HASH(HeKEY_hk(he))
+#define HePV(he)		((HeKLEN(he) == HEf_SVKEY) ?		\
+				 SvPV(HeKEY_sv(he),na) :		\
+				 HeKEY(he))
+#define HeSVKEY(he)		((HeKEY(he) && 				\
+				  HeKLEN(he) == HEf_SVKEY) ?		\
+				 HeKEY_sv(he) : Nullsv)
+
+#define HeSVKEY_force(he)	(HeKEY(he) ?				\
+				 ((HeKLEN(he) == HEf_SVKEY) ?		\
+				  HeKEY_sv(he) :			\
+				  sv_2mortal(newSVpv(HeKEY(he),		\
+						     HeKLEN(he)))) :	\
 				 &sv_undef)
+#define HeSVKEY_set(he,sv)	(HeKEY_sv(he) = sv)
+
+#define HK_LEN(hk)		(hk)->hk_len
+#define HK_KEY(hk)		(hk)->hk_key
+#define HK_HASH(hk)		(hk)->hk_hash