Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
tag: timinatorII
Commits on May 15, 1998
  1. [differences between patch application from Change 984 and Change 985]

    Tim Bunce authored
     Title:  "ExtUtils::Manifest could truncate files during "make dist""
      From:  "James E Jurach Jr." <muaddib@arrakis.int.ein.cz>,
             koenig@kulturbox.de (Andreas J. Koenig)
    Msg-ID:  <199805111048.MAA02573@arrakis.int.ein.cz>,
             <sfc90o8bgie.fsf@dubravka.in-berlin.de>
     Files:  lib/ExtUtils/Manifest.pm
    
     Title:  "AutoSplit/AutoLoaded subs: give useful line numbers in warnings etc"
      From:  "Jesse N. Glick" <jglick@sig.bsh.com>, koenig@anna.mind.de (Andreas
             J. Koenig), larry@wall.org (Larry Wall)
    Msg-ID:  <199709292015.NAA09627@wall.org>, <342FCDDF.23534195@sig.bsh.com>,
             <sfc202c9jsb.fsf@anna.in-berlin.de>,
             <sfc3efg5rhg.fsf@dubravka.in-berlin.de>
     Files:  lib/AutoSplit.pm
    
    p4raw-link: @984 on //depot/maint-5.004/perl: aaffd3c
    p4raw-id: //depot/maint-5.004/perl@985
  2. Autosplit doesn't like upper case letters in sub names on VMS

    Dan Sugalski authored Tim Bunce committed
    Autosplit.PM mis-behaves a bit on VMS. When it creates its auto-split
    .al files, it assumes that the filename will be the same as the sub name
    including case. This turns out not to be the case for VMS, whose file
    system upcases all filenames, and whose CRTL then downcases all filenames.
    Any sub whose name has an uppercase letter in it will end up with a file with
    an all-lowercase name.
    
    This would not be a problem, except that the autosplit_file sub then goes and
    deletes any .al files whose names do not exactly match (including case) the
    names of a sub. This nukes the (lower-cased filename) files for any sub
    that's got upper-case letters in its name, which pretty much kills the module
    build.
    
    The following patch fixes this for VMS. Current behavior's preserved for
    everyone else, of course. (The -V output at the end is incorrect in this
    case--the patch was made to my 5.004_04 sources, and tested with them)
    
    p5p-msgid: 3.0.5.32.19980330152332.009cb130@osshe.edu
  3. allow die $ref

    Graham Barr authored Tim Bunce committed
    Tim Bunce wrote:
    > 
    > Does
    >         eval { die $ref };
    >         die if $@;
    > 
    > propagate the original ref?
    
    No, but here is a new patch against perl5.004_04-m1 which does
    
    > Are 'we' happy to loose the "\n...propagated at ..." functionality
    > of a die without arguments when $@ contains a ref? I guess it's the
    > only reasonable way to go.
    
    Well this is what started off the definition of Error.pm. The thought
    was that maybe that if $ref is an object it should support a given
    API. Then we could have methods for propagate and stringify which
    perl would call at appropriate times.
    
    Credited: Tim Bunce <Tim.Bunce@ig.co.uk>
    Credited: Tim.Bunce@ig.co.uk (Tim Bunce) (Tim Bunce)
    
    p5p-msgid: 355C3E67.AF25B9F7@ti.com
    Credited: Tim Bunce <Tim.Bunce@ig.co.uk>
    Credited: Tim.Bunce@ig.co.uk (Tim Bunce) (Tim Bunce)
  4. [differences between patch application from Change 982 and Change 984]

    Tim Bunce authored
     ------  CORE LANGUAGE  ------
    
     Title:  "Fix close pipe returning status from wrong child"
      From:  "M.J.T. Guy" <mjtg@cus.cam.ac.uk>, kstar@chapin.edu@ig.co.uk ()
    Msg-ID:  <199805142313.TAA02684@chapin.edu>,
             <E0yZ8ah-0005d8-00@taurus.cus.cam.ac.uk>
     Files:  t/io/pipe.t util.c
    
     Title:  "Avoid English.pm triggering load of Errno.pm"
      From:  Tim Bunce
     Files:  gv.c lib/English.pm
    
     ------  EXTENSIONS  ------
    
     Title:  "BSD Platforms need STRUCT_TM_HASZONE for POSIX"
      From:  Andy Dougherty <doughera@lafcol.lafayette.edu>
    Msg-ID:  <Pine.SUN.3.96.980512095524.8158C-100000@newton.phys>
     Files:  MANIFEST ext/POSIX/hints/bsdos.pl ext/POSIX/hints/freebsd.pl
             ext/POSIX/hints/netbsd.pl ext/POSIX/hints/openbsd.pl
    
     ------  TESTS  ------
    
     Title:  "Fix constant detection in t/op/ipcsem.t for Digit UNIX"
      From:  Jarkko Hietaniemi <jhi@iki.fi>
    Msg-ID:  <199805121212.PAA15351@alpha.hut.fi>
     Files:  t/op/ipcsem.t
    
     Title:  "Fix doc bug for system() return value"
      From:  Daniel Grisinger <dgris@perrin.dimensional.com>
    Msg-ID:  <Pine.LNX.3.96.980514165608.4062A-100000@perrin.dimensional.com>
     Files:  pod/perlfunc.pod t/op/exec.t
    
     ------  UTILITIES  ------
     Title:  "Avoid possible constant autoload loop"
      From:  "M.J.T. Guy" <mjtg@cus.cam.ac.uk>, Graham Barr <gbarr@ti.com>, Ilya
             Zakharevich <ilya@math.ohio-state.edu>
    Msg-ID:  <199805141910.PAA26994@monk.mps.ohio-state.edu>,
             <355B475A.C5AD4B90@ti.com>,
             <E0ya11X-0000hm-00@taurus.cus.cam.ac.uk>
     Files:  utils/h2xs.PL
    
       (applied based on p5p message as
        483d93a, this change contains the
        difference)
    
    p4raw-link: @982 on //depot/maint-5.004/perl: c5ed518
    p4raw-id: //depot/maint-5.004/perl@984
  5. Further improvements to h2ph.PL

    Kurt Starsinic authored Tim Bunce committed
        Following is a patch for h2ph.PL, against perl5.004_04-m2.  I've
    done a decent amount of testing on it, and it works, IMHO, at least
    as well as any previous h2ph.
    
        FYI, it's still not perfect (surprise!).  For example, Solaris
    2.5.1's stdio.h has the following line in it:
    
            #define NULL (__NULL_TYPE 0)
    
        which maps to:
    
            eval 'sub NULL () {( &__NULL_TYPE 0);}' unless defined(&NULL);
    
        which gives the error:
    
            Number found where operator expected at stdio.ph line 5,
                near "&__NULL_TYPE 0" (Missing operator before  0?)
    
        But this is typecasting, which is durned near impossible to get
    right in the general case.
    
    p5p-msgid: 199805130241.WAA25459@chapin.edu
  6. @jhi

    Fix constant detection in t/op/ipcsem.t for Digit UNIX

    jhi authored Tim Bunce committed
    (sent also to perlbug and Tim, not sent to p5p at first because of a typo...)
    
    As I said earlier the look-for-cpp-defines testing in t/op/ipc*.t was
    broken, doomed, DOOMED.  For example the #include logic was broken,
    twice: (1) something called $mm was the name of the #included file
    (2) filehandle F was not local()ized.  Because of this much breakage
    in Digital UNIX the S_IRWX[UGO] could not be found because they are
    not directly in <sys/stat.h>.
    
    IMNSHO The Right Way would be to create SysV::IPC (or IPC::SysV, whatever)
    that contains the right constants, a la Fcntl.  I already took a shot at
    this and found that one must sample several systems to garner all the IPC*,
    SHM* SEM*, GET*, et alia constants.  If somebody feels like they know enough
    of SVIPC (I don't) they can have what I've got scraped together.
    
    However: I pushed the doom a little bit farther.  With this patch
    Digital UNIX 4.0D is happy with 04-m2.  Mucho diagnostic output related
    to the #include groveling added, they might come in handy when this
    rickety house of cards falls down the next time.  When, not if.
    
    p5p-msgid: 199805121212.PAA15351@alpha.hut.fi
  7. Avoid possible constant autoload loop

    M.J.T. Guy authored Tim Bunce committed
    I attempted to install the SNMP-1.7 module, but 'make test' failed.
    To find what was happening, I tried to run the particular test directly.
    But I made the standard mistake of forgetting the   -Iblib/auto    on
    the command line, so I quite rightly got
    
    %perl5.004_04g -Iblib/lib t/session.t
    Can't locate loadable object for module SNMP in @INC (@INC contains: blib/lib /home/mjtg/perl5.004_04g/lib /home/mjtg/perl5.004_04g/lib /home/mjtg/perl5.004_04g/lib .) at t/session.t line 12
    BEGIN failed--compilation aborted at t/session.t line 12.
    
    But then it went into a loop, which I didn't expect.
    
    This is because
    
    i)  SNMP.pm has an END {} subroutine, which is (of course) installed
        at compile time.
    
        END{SNMP::_sock_cleanup();}
    
    ii) It incorporates the constant autoloader from XS:
    
    sub AUTOLOAD {
        # This AUTOLOAD is used to 'autoload' constants from the constant()
        # XS function.  If a constant is not found then control is passed
        # to the AUTOLOAD in AutoLoader.
        my($val,$pack,$file,$line);
        local($constname);
        ($constname = $AUTOLOAD) =~ s/.*:://;
        $val = constant($constname, @_ ? $_[0] : 0);
        if ($! != 0) {
            if ($! =~ /Invalid/) {
                $AutoLoader::AUTOLOAD = $AUTOLOAD;
                goto &AutoLoader::AUTOLOAD;
            }
            else {
                ($pack,$file,$line) = caller;
                die "Your vendor has not defined SNMP macro $constname, used at $file line $line.
    ";
            }
        }
        eval "sub $AUTOLOAD { $val }";
        goto &$AUTOLOAD;
    }
    
    So when the compilation fails, the END subroutine is called.   Since the
    subroutine _sock_cleanup isn't defined, AUTOLOAD is called.   But since
    the subroutine constant isn't defined, we now go into an AUTOLOAD
    recursion.
    
    An obvious fix is to defer establishing the END{} subroutine by putting it
    inside an eval ''  -  patch attached.
    
    But this style must be common to very many modules, so it seems worth
    considering more general fixes.
    
    a)    Should END{} subroutines be run if compilation fails?
          I suggest that END{} subroutines should not be installed
          immediately on compilation, but should be placed on a deferred
          list, and only moved to the main list on completion of
          compilation.
    
    b)    The XS constant autoloader should check for the particular name
          "constant" and die.    Again patch attached.
    
          But of course this patch won't be effective, since historical
          copies of the autoloader are bound into every module in the
          known universe.    Why wasn't this made into a separate module
          inherited by XS modules as required, in accordance with standard
          world-saving procedures?
    
    Credited: Graham Barr <gbarr@ti.com>
    Credited: Ilya Zakharevich <ilya@math.ohio-state.edu>
    
    p5p-msgid: E0ya11X-0000hm-00@taurus.cus.cam.ac.uk
  8. Appease picky DEC compiler in POSIX.xs

    Dan Sugalski authored Tim Bunce committed
    (Ignore the last patch to POSIX.XS--it was really old. Grabbed the
    wrong one from my out box. This is the correct one. It was originally
    against 5.004_5x, but it's needed for _05, too)
    
    The latest Dec C (5.7) is amazingly picky, and has come across a few
    problems that have probably been lurking for a while. The following
    patch fixes things up so it's happy.
    
    p5p-msgid: 3.0.5.32.19980511161434.009f8bb0@ous.edu
  9. MM_VMS.pm fixes for building external library

    Dan Sugalski authored Tim Bunce committed
    (I originally sent this out a while ago (back in january), but it didn't make it into the _05 patchkit. Here it is again)
    
    Okay, folks. Here's a patch for MM_VMS.PM that fixes a bug when building
    an extension with an external library. (like, say, SDBM_File or GD) It's not
    perfect (will still fail under certain circumstances, but fewer than the
    current version, and all currently functional cases still work) but it's good
    enough to fix a majority of the cases *and* get SDBM_File to build (whith the
    SDBM_File patches needed for VMS, of course)
    
    p5p-msgid: 3.0.5.32.19980511160542.009dd480@ous.edu
  10. Document child exit cause a parent sleep to end early

    M.J.T. Guy authored Tim Bunce committed
    Damon Atkins <Damon.Atkins@nabaus.com.au> wrote
    
        [ example showing sleep() being interrupted by SIGCHLD ]
    
    The documentation isn't as explicit as it should be that sleep() is
    terminated by _any_ signal, not just SIGALRM.   Patch below.
    
    Note also that you can use the return value to decide if you have
    slept for the full interval, and do an additional sleep() if desired.
    
    p5p-msgid: E0yZwMK-0000D9-00@taurus.cus.cam.ac.uk
  11. Title: "comment init_postdump_symbols issues"

    Tim Bunce authored
      From:  Tim Bunce
     Files:  perl.c
    
     Title:  "Improve sort docs re SUBNAME"
      From:  circle@azstarnet.com
    Msg-ID:  <199804281828.LAA22737@andromeda.azstarnet.com>
     Files:  pod/perlfunc.pod
    
    p4raw-id: //depot/maint-5.004/perl@982
  12. "Add hook to tie %! to external Errno.pm module (not included)"

    Graham Barr authored Tim Bunce committed
    Msg-ID:  <355080CD.1111BC81@ti.com>
     Files:  gv.c
    
    p4raw-id: //depot/maint-5.004/perl@981
Commits on May 14, 1998
  1. "fix C<print "foo ${\()}"> (pp_refgen fumbles when G_SCALAR, no args)"

    Gurusamy Sarathy authored Tim Bunce committed
    Msg-ID:  <199805070402.AAA02858@aatma.engin.umich.edu>
     Files:  pp.c
    
    p4raw-id: //depot/maint-5.004/perl@971
  2. "perlbug reformatted"

    Dominic Dunlop authored Tim Bunce committed
             <hv@crypt0.demon.co.uk>
    Msg-ID:  <199805110954.LAA20367@dorlas.elsevier.nl>,
             <l03130300b17cebcb6d33@[194.222.64.89]>,
             <v03110702b17ccbab6824@[195.95.102.67]>
     Files:  utils/perlbug.PL
    
    p4raw-id: //depot/maint-5.004/perl@970
  3. "Sub declaration cost reduced from ~500 to ~100 bytes"

    Ilya Zakharevich authored Tim Bunce committed
    Msg-ID:  <199805050607.CAA02050@monk.mps.ohio-state.edu>
     Files:  gv.h gv.c op.c
    
    p4raw-id: //depot/maint-5.004/perl@965
  4. "while($x=<>) no longer warns (implicit defined added)"

    Nick Ing-Simmons authored Tim Bunce committed
    Msg-ID:  <199805051035.LAA27365@pluto.tiuk.ti.com>
     Files:  MANIFEST op.c t/op/defins.t
    
    p4raw-id: //depot/maint-5.004/perl@949
  5. "Fix PERL_DESTRUCT_LEVEL core dumps"

    Gurusamy Sarathy authored Tim Bunce committed
    Msg-ID:  <199805062301.TAA24599@aatma.engin.umich.edu>
     Files:  perl.c sv.c t/op/misc.t
    
    p4raw-id: //depot/maint-5.004/perl@946
  6. "5.004_04-m2 Cleanup of test failures"

    Gurusamy Sarathy authored Tim Bunce committed
    Msg-ID:  <199805070416.AAA03082@aatma.engin.umich.edu>
     Files:  t/op/die_exit.t t/op/ipcmsg.t t/op/ipcsem.t t/op/taint.t
             win32/config.bc win32/config.vc
    
    p4raw-id: //depot/maint-5.004/perl@944
Commits on May 11, 1998
  1. [difference between patch application from Change 913 and Change 922]

    Tim Bunce authored
     ------  DOCUMENTATION  ------
    
     Title:  "tweak doc for C<do FILENAME>"
      From:  Gurusamy Sarathy <gsar@engin.umich.edu>
    Msg-ID:  <199805090017.UAA06888@aatma.engin.umich.edu>
     Files:  pod/perlfunc.pod
    
     ------  PORTABILITY - GENERAL  ------
    
     Title:  "Add Porting/patching.pod document"
      From:  Daniel Grisinger <dgris@tdrenterprises.com>
    Msg-ID:  <199805030305.XAA16147@relay.pair.com>
     Files:  MANIFEST Porting/patching.pod
    
     Title:  "Add VMS specifics to Porting/makerel"
      From:  Charles Bailey <BAILEY@newman.upenn.edu>
    Msg-ID:  <01IWDK1LONRQ0026P0@cor.newman.upenn.edu>,
             <199804271732.SAA13762@toad.ig.co.uk>,
             <9804250212.AA27695@forte.com>
     Files:  Porting/makerel
    
    p4raw-link: @913 on //depot/maint-5.004/perl: 91b1e15
    p4raw-id: //depot/maint-5.004/perl@922
  2. Add VMS specifics to Porting/makerel

    Charles Bailey authored Tim Bunce committed
    Funny - I had intended to submit a patch against _04 to fix 
    File::Path::mkpath() which had a nasty problem (especially on VMS).  
    A closer look at the 04-m1 source revealed that the necessary 
    change is already in there (thanks!).
    
    I did, however, encounter build troubles on VMS one of which involved 
    the new save_helem() and save_aelem() in pp.c pp_hot.c not having 
    prototypes.  I hand applied the proto.h fix from Gurusamy Sarathy in:
    
      http://www.rosat.mpe-garching.mpg.de/
        mailing-lists/perl-porters/1998-03/msg00469.html
    
    and got further along to:
    
    MCR Sys$Disk:[]miniperl.exe "-I[.lib]" ConfigPM.
    Create/Directory [.lib.VMS_AXP.5_00404]
    %CREATE-I-EXISTS, [.LIB.VMS_AXP.5_00404] already exists
    Copy [.LIB]CONFIG.PM [.LIB.VMS_AXP.5_00404]CONFIG.PM
    %MMS-F-GWKNOPRN, There are no known sources for the current target [.EXT.DYNALOADER]DYNALOADER.PM.
    
    Unfortunately the .PL-ification of Dynaloader.pm was not accounted for
    in the VMS Makefile.  The enclosed patch to vms/descrip.mms fixes that.
    
    I realize that there have been many patches to vms related files recently, 
    perhaps including vms/descrip.mms.  Unfortunately I have not had the time 
    to check if this change was already suggested and/or incorporated into 
    the archive (though I did search the p5p and vmsp archives at 
    www.rosat.mpe-garching.mpg.de for the string '_pl' but saw nothing relevant 
    to vms).  Apologies to the pumpking for any inconvenience (and 
    congratulations on the new baby :-).
    
    Do note that the change to PERL_VERSION reflected in this patch
    ought to be upped (via C<s/00404/00405/>) before releasing this
    as _05.
    
    Peter Prymmer
    pvhp@forte.com
    
    Single file affected: vms/descrip.mms
    Apply with: patch -p0 < this_patch
    
    Credited: Peter Prymmer <pvhp@forte.com>
    
    p5p-msgid: 9804250212.AA27695@forte.com
  3. hints/machten.sh: disable semctl(), align with devel version

    Dominic Dunlop authored Tim Bunce committed
    semctl(.., .., IPC_STATUS, ..) hangs the system on MachTen 4.1.  Here's a
    patch to make hints/machten.sh assert that semctl() isn't available.  The
    patch also brings the maintenance track hints file into line with that in
    the development track, which is slightly more up-to-date.
    
    p5p-msgid: v03110701b175fc029eb1@[195.95.102.115]
  4. Fix File::Find::finddepth typo in trial 2 release

    Andreas J. Koenig authored Tim Bunce committed
    Subject: 5.004_04-m2: File::Find::finddepth is gone
    
    It looks just like a typo. I've added a test to findfind.t too.
    
    p5p-msgid: sfcbttflsjz.fsf@dubravka.in-berlin.de
  5. Clarify Termios usage in POSIX.pod

    Rocco Caputo authored Tim Bunce committed
    The included patch removes some ambiguity from the POSIX::Termios
    documentation.
    
    p5p-msgid: 199805101952.PAA12738@ns.netrus.net
  6. Reduce rm command line length in pod/Makefile

    Hugo van der Sanden authored Tim Bunce committed
    Subject: [PATCH] Re: mostly OK: perl 5.00404 +MAINT_TRIAL_2 on sun4-solaris 
    
    :This is a success report for perl from h.sanden@elsevier.nl,
    :generated with the help of perlbug 1.20 running under perl 5.00404.
    :
    :Perl reported to build mostly OK on this system: op/ipc* both failed
    :under 'make test', but succeeded when run individually. I assume this
    :failure relates to the problems noted by Jarkko - I don't have time
    :to investigate this right now.
    
    Building the same with DEBUGGING passed all tests (additional configure
    option '-Dccflags="-g -DDEBUGGING"').
    
    I also note that 'make clean' in ./pod is producing an 'rm' line
    2181 characters long: patch below splits the line into 3. (I assume
    the Makefile isn't generated.)
    
    p5p-msgid: 199805041423.QAA13199@dorlas.elsevier.nl
  7. @gisle

    Document integer pragma effect on % operator

    gisle authored Tim Bunce committed
    Jon Orwant <orwant@media.mit.edu> writes:
    
    > Of course I expect "use integer" to use integers for everything.  
    > I don't see why that should change the value of -534 % 210.  
    > 
    > Here's what perlmod says:
    >  
    >    Binary "%" computes the modulus of two numbers.  Given integer operands $a
    >    and $b: If $b is positive, then $a % $b is $a minus the largest multiple of
    >    $b that is not greater than $a.  If $b is negative, then $a % $b is $a
    >    minus the smallest multiple of $b that is not less than $a (i.e. the result
    >    will be less than or equal to zero).
    > 
    > $a is -534.  $b is 210.  The largest multiple of 210 not greater than -534
    > is -630.  Ergo, -534 % 210 is -534 - -630, or 96.  
    > 
    > But if you "use integer", you get -114.  Arithmetic Most Foul.
    
    I think it should stay the way it is.  Perhaps we should apply this
    documentation patch.
    
    p5p-msgid: m3yawjmzhx.fsf@furu.g.aas.no
  8. Remove dead code from pod2man

    M.J.T. Guy authored Tim Bunce committed
    This fragment of code was left behind when the .IX fix was made to
    pod2man.    Since the X<> construct isn't used anywhere in the core pods,
    this is currently something of a non-bug.    It also means that this patch
    is untested.  :-)
    
    p5p-msgid: E0yXmuT-0006Ll-00@ursa.cus.cam.ac.uk
  9. Improve docs for warning about code after an exec()

    M.J.T. Guy authored Tim Bunce committed
    I wrote
    > This probably ought to be in   perldoc -f exec.
    
        ... and here it is.
    
    Credited: Chaim Frenkel <chaimf@concentric.net>
    
    p5p-msgid: E0yYUit-0003yb-00@taurus.cus.cam.ac.uk
  10. perlvar.pod buglet E<EVMSERR>

    Achim Bohnet authored Tim Bunce committed
    Besides the already reported two IPC tests that fail on Digital Unix
    make install gave:
      ...
      ../pod/pod2man: Unknown escape in paragraph 156 of perlvar.pod: ``E<EVMSERR>''
      ...
    
    Jarkko posted a patch for _59 back in Feb (last hunk in
    http://www.rosat.mpe-garching.mpg.de/mailing-lists/perl-porters/1998-02/msg01933.html
    ):
    
    ...
    
    p5p-msgid: 9805041415.AA22185@o09.xray.mpe.mpg.de
  11. incorrect return value for hv_iterinit

    Gurusamy Sarathy authored Tim Bunce committed
    On Sat, 02 May 1998 16:29:22 EDT, "SynaptiCAD, Inc." wrote:
    >While doing so and debugging the wrapper we found an error in the
    >hv_iterinit function. It doesn't say in the code, but in
    >Srinivasan's "Advanced perl Programming" book he indicates that
    >the return value is the number of elements placed in the hash table
    >(which seems logical). The error is that the routine is returning xhv_fill
    >instead of xhv_keys. There is actually a comment on the line that
    >is suggesting this line be changed, but it looks like it never was
    >made (at leat not in the latest developer update on CPAN).
    
    It's in now.  In one corner of the repository.
    
    p5p-msgid: 199805031848.OAA20618@aatma.engin.umich.edu
Commits on May 1, 1998
  1. Update MANIFEST for trial 2.

    Tim Bunce authored
    (Porting/Contract lib/Tie/Handle.pm t/op/tiehandle.t)
    
    p4raw-id: //depot/maint-5.004/perl@913
  2. Add t/op/tiehandle.t as xtext to repository (see change 911)

    Tim Bunce authored
    p4raw-id: //depot/maint-5.004/perl@912
  3. Title: "Add ERRSV, ERRHV, DEFSV and SAVE_DEFSV for XS 5.005 compatib…

    Tim Bunce authored
    …ility"
    
      From:  timbo@ig.co.uk (Tim Bunce)
    Msg-ID:  <199804200854.JAA01482@toad.ig.co.uk>
     Files:  perl.h
    
     Title:  "Add WRITE & CLOSE to TIEHANDLE"
      From:  Graham Barr <gbarr@pobox.com>
    Msg-ID:  <34F63DC8.CA95670F@pobox.com>
     Files:  pod/perltie.pod lib/Tie/Handle.pm pp_sys.c t/op/tiehandle.t
    
    p4raw-id: //depot/maint-5.004/perl@911
  4. [difference between patch application from Change 909 and Change 910]

    Tim Bunce authored
     Title: "Add warning for Illegal hex digit"
     Files:  util.c
    
       (applied based on p5p patch as
       b4ee34b, this is the difference)
    
    p4raw-link: @909 on //depot/maint-5.004/perl@909: 8b3d696
    p4raw-id: //depot/maint-5.004/perl@910
  5. Document changed local($a[$i],$b{$j}) behaviour re delete/splice

    Charles Bailey authored Tim Bunce committed
    Just a quick doc update; I've presumed that given the split discussion
    on p5p the original fix will stay around.
    
    p5p-msgid: 01IVMVIHNZ36001NKH@cor.newman.upenn.edu
  6. Fix printf segmentation fault

    Hugo van der Sanden authored Tim Bunce committed
    At 12:52 pm -0400 28/4/98, Ilya Zakharevich wrote:
    >Hugo van der Sanden writes:
    >> Using 5.004_05t1, the below gives an assertion failure:
    >>   for ($i=0; $i<124; ++$i) {
    >>       $data{$i}++;
    >>   }
    >>   foreach (0 .. 123) {
    >>       @x = split(" ",undef);
    >>       printf("%s%3d %s%6d\n",$x[0],$x[1],$x[2],$_);
    >>   }
    >> Run inside gdb with '-w /home/hsanden/t0', I get:
    >>   Name "main::data" used only once: possible typo at /home/hsanden/t0 line 2.
    >>   Use of uninitialized value at /home/hsanden/t0 line 5.
    >>   assertion botched: *(unsigned int *)((caddr_t)Perl_op + Perl_op->ovu.ovu_size + 1 - sizeof (unsigned int)) == 0x55555555
    >
    >For those who have never seen it: This is a memory overrun.  Write was
    >performed after an end of the malloced area.
    
    Thanks Ilya - I hadn't seen it before.
    
    I understand, I think, why it is happening: the $x[??] arguments to printf
    are being compiled to pp_aelemfast, which pushes on the stack without
    bounds checking - the second one exactly fills the stack, so the third
    writes past the end; the final $_ is pp_gvsv, which does an EXTEND(sp, 1),
    which grows the stack, copying all that it knows about, but leaving a
    gap for the past-the-end value - this causes the SEGV when the overwrite
    hasn't been trapped by the assertion.
    
    I'm not sure whether AELEMFAST is supposed to EXTEND - if it is, the patch
    below will suffice. If not, then presumably room on the stack is supposed
    to be guaranteed at the time of generation of the op, which is in
    op.c:peep() case OP_GV: I can't see there any attempt to check expected
    stack depth.
    
    I can certainly see the value of optimising the printf to something along
    the lines of:
      EXTEND SP, 5
      MARK
      CONSTFAST
      AELEMFAST
      AELEMFAST
      AELEMFAST
      SCALARFAST
      PRINTF
    
    .. but I suspect that isn't what 'FAST' is supposed to mean.
    
    Patch is to 5.004_04, and passes all tests (and the above failure case)
    here; it might be worth adding the failure case to op/misc.t if it is
    at least reasonably likely to fail in the same place in the future - if
    so, only the last four lines should be required.
    
    p5p-msgid: l03130300b16bebdbc314@[194.222.64.89]
Something went wrong with that request. Please try again.