kevin@kosman.UUCP (Kevin O'Gorman) (11/25/90)
It looks like taintperl is now thouroughly impossible on a 3b1 -- the switch case in teval.c is just too big for the compiler. I changed it to link perl to taintperl. I've got a single-user system anyway -- why should I waste time on security features? On the other hand, hasn't this gone on long enough? Larry?? The results work okay, except that the dbm test fails on 3 -- an attempt to do a foreach on an empty array. I'm not really sure what I'm using for dbm... Anyone know where there's a good one to snarf? -- Kevin O'Gorman ( kevin@kosman.UUCP, kevin%kosman.uucp@nrc.com ) voice: 805-984-8042 Vital Computer Systems, 5115 Beachcomber, Oxnard, CA 93035 Non-Disclaimer: my boss is me, and he stands behind everything I say.
clewis@ecicrl.UUCP (Chris Lewis) (12/01/90)
In article <1263@kosman.UUCP> kevin@kosman.UUCP (Kevin O'Gorman) writes: >It looks like taintperl is now thouroughly impossible on a 3b1 -- the >switch case in teval.c is just too big for the compiler. I changed it >to link perl to taintperl. I've got a single-user system anyway -- why >should I waste time on security features? I don't know what your problem is, but we've never had trouble compiling any patch level of Perl on our 3b1's. We're 3.5.1.4 release of the O/S (oldish) with 2Mb, are you something even older? teval.c is copied from eval.c and the TAINT definition during compile doesn't make all that much difference. Eg: if 320 clauses was too many, you'd have blown the compile of eval.c too and not been able to compile Perl at all. In fact, we use our 3b1's as a yacc server for compiling Perl on a 386/ix 1.0.6 system because the yacc on that release is too small to handle Perl. Mind you, eval.c and one of the other source files blows the optimizers on a number of O/S's (386/ix 1.0.6 and RS/6000 comes to mind) And finally, that 320 clause siwtch statement makes me feel good about psroff - I've had one or two complaints that the 256 clauses in a switch in psroff is too many ;-) (it works fine with my 3b1) >On the other hand, hasn't this gone on long enough? Larry?? >The results work okay, except that the dbm test fails on 3 -- an attempt >to do a foreach on an empty array. I'm not really sure what I'm using >for dbm... Anyone know where there's a good one to snarf? What did it use? Chances are it didn't use any (eg: all assoc arrays incore) unless you explicitly imported mdbm or ndbm because ol' dbm doesn't come standard on 3b1 releases that I know of. On that front, it appears that Ozan's PD sdbm will be a freely redistributable full-feature dbm that works with Perl (don't ask him or me for it because it's still under test and needs a little work before release) BTW: I'm getting core-dumps with PL41 too (though the regression tests work perfectly), am still investigating. -- Chris Lewis, Phone: (613) 832-0541 UUCP: uunet!utai!lsuc!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Psroff mailing list (psroff-request@eci386)
les@chinet.chi.il.us (Leslie Mikesell) (12/03/90)
In article <973@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >And finally, that 320 clause siwtch statement makes me feel good about >psroff - I've had one or two complaints that the 256 clauses in a >switch in psroff is too many ;-) (it works fine with my 3b1) Both psroff and perl fail to compile on a 3b2/400 because of the small switch table in the compiler. I've been told that a replacement compiler is available, though. >>On the other hand, hasn't this gone on long enough? Larry?? Yes, especially now that a similar complaint about eval.c was posted about AUX. Time to fix it if you want to be able to continue claiming that perl is more portable than sh. Les Mikesell les@chinet.chi.il.us