Segfault in dataentry() (PR#391)

[maechler@stat.math.ethz.ch]

>>>>> "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?

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