Segfault in dataentry() (PR#391)

[Kurt Hornik]

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