maechler writes:
"PD" == p dalgaard <p.dalgaard@pubhealth.ku.dk> writes:
dataentry(0,0)
PD> Program received signal SIGSEGV, Segmentation fault. 0x808991c in
PD> duplicate (s=0x0) at ../../../R/src/main/duplicate.c:42 42 switch
PD> (TYPEOF(s)) {
PD> Apparently that one doesn't get trapped by the no-segfault checks.
PD> Martin?
There's a not-so-short "stop.list" of functions which are *NOT* tested for segfaults. dataentry (w/ and w/o ".") is among them. all the interactive ones are, actually. [[remember: The list was quite a bit shorter, and there were R core members who complained...]]
Look in ..../tests/make-no-segfault.R for the statements starting with
edit.int <- c("fix", "edit", "vi", "emacs", "pico", "xemacs", "xedit")
misc.int <- c("browser", "bug.report", "menu")
stop.list[["base"]] <-
..
to find all the functions which are *not* tested for seg.faults.
Maybe we (R-core) we should really always have
R_TESTLOTS=yes
in our environments?
Actually, I'd prefer having some means of markup in the Rd source code to indicate whether an object should not be employed for the no-segfault testing. We could still keep the R_TESTLOTS, though ... E.g, the socket docs would have something correspding to \dontrun in the examples section. This should be cleaner than having to change the script in tests. (Confusion arose when Fritz added old.packages() two days ago ...) -k -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html Send "info", "help", or "[un]subscribe" (in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch _._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._