Return to BSD News archive
Newsgroups: comp.os.386bsd.misc Path: sserve!newshost.anu.edu.au!munnari.oz.au!constellation!osuunx.ucc.okstate.edu!newsfeed.ksu.ksu.edu!moe.ksu.ksu.edu!vixen.cso.uiuc.edu!sdd.hp.com!ihnp4.ucsd.edu!news.cerf.net!netlabs!lwall From: lwall@netlabs.com (Larry Wall) Subject: Re: Perl[45] for FreeBSD 1.1 [GR]...? Message-ID: <1994Jun2.185010.1120@netlabs.com> Organization: NetLabs, Inc. References: <JKH.94May26024328@morse.ilo.dec.com> <2s8dum$hjt@ucthpx.uct.ac.za> <MARK.94May31174920@jupiter.aggregate.com> Date: Thu, 2 Jun 1994 18:50:10 GMT Lines: 29 In article <MARK.94May31174920@jupiter.aggregate.com> mark@jupiter.aggregate.com (Mark P. Gooderum, Software Engineer) writes: : : > Last time I looked, the perl that this builds fails one : > of the tests in the testsuite that comes with perl, something : > that tests dbm . has anyone fixed this? : : This has been covered before...it isn't a bug in perl or in the OS, it : is a bug in the perl test. The perl test assumes it knows the : filenames created by the dbm library. The BSD 4.4 dbm lib used in : Free/NetBSD creates only one file with a different name than either of the : files created by the original implementation. : : The test in question merely does a dbm_open() and some bits and looks : for the file. You can fix the test to look for the right filename but : this is broken anyways, IMHO...if the db routines pass their : functional tests, which they do, thats enough. A perl (or any other : "application" test shouldn't assume anything about the db implementation. Well, you can take that tack, but in Perl 5 we allow multiple dbm-ish implementations to co-exist in one executable, so we test each of 'em separately. There may well be things that the specific interfaces want to have tested which aren't testable (or not easily testable) through the generic interface. The DB package in particular is likely to supply extra methods that aren't used by the generic interface. (Although the generic interface is even more generic, letting you tie more than just associative arrays to more than just DBM files). Larry Wall lwall@netlabs.com