Segfault in dataentry() (PR#391)

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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._