http://www.keittlab.org/
On Wed, May 25, 2016 at 10:43 AM, <luke-tier...@uiowa.edu> wrote: > On Wed, 25 May 2016, Tim Keitt wrote: > > On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence < >> lawrence.mich...@gene.com >> >>> wrote: >>> >> >> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms <jeroen.o...@stat.ucla.edu> >>> wrote: >>> >>> >> I'm not disagreeing with what's been said in this thread, but I can't help >> but recall that I brought up this exact issue probably 15 years ago and >> was >> told (by Brian, I believe) "don't do that" (pass a null pointer), which >> was >> perfectly fine. The real issue was not the behavior but that it was not >> documented or consistent. I've lived by the mantra since that you can >> never >> trust a pointer in R code. User must always check for NULL. >> > > In _C_ code. This is true whether you are calling into the R C API or > any other C library: you as the C programmer need to make sure either > that passing NULL is OK or make sure you don't do that. > I agree -- I meant it was "perfectly fine" to remind us we need to check pointers. Its really a documentation issue. THK > > I wouldn't object to mkXXX checking for NULL and signaling an error > instead of segfaulting, but good C code calling mkXXX should still > typically do its own check and handle the situation in an appropriate > way. > > Best, > > luke > > > >> I just wrote my own functions mkXXX_safe that wrap the internals and check >> the pointer. >> >> THK >> >> http://www.keittlab.org/ >> >> [[alternative HTML version deleted]] >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >> > -- > Luke Tierney > Ralph E. Wareham Professor of Mathematical Sciences > University of Iowa Phone: 319-335-3386 > Department of Statistics and Fax: 319-335-3017 > Actuarial Science > 241 Schaeffer Hall email: luke-tier...@uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu > [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel