On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence <lawrence.michael at gene.com> wrote:> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms <jeroen.ooms at 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. 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]]
luke-tierney at uiowa.edu
2016-May-25 15:43 UTC
[Rd] Suggestion: mkString(NULL) should be NA
On Wed, 25 May 2016, Tim Keitt wrote:> On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence <lawrence.michael at gene.com >> wrote: > >> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms <jeroen.ooms at 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 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 at 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-tierney at uiowa.edu Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu
http://www.keittlab.org/ On Wed, May 25, 2016 at 10:43 AM, <luke-tierney at uiowa.edu> wrote:> On Wed, 25 May 2016, Tim Keitt wrote: > > On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence < >> lawrence.michael at gene.com >> >>> wrote: >>> >> >> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms <jeroen.ooms at 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 at 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-tierney at uiowa.edu > Iowa City, IA 52242 WWW: http://www.stat.uiowa.edu >[[alternative HTML version deleted]]
Hi, I tend to agree with the objections expressed earlier. I would only add that making the NULL pointer semantically equivalent to NA would introduce a precedent that could lead to some confusion. For example it would set the expectation that CHAR(Rf_mkChar(NULL)) is NULL, which is not the case AFAIK. Or that low-level string manipulation utilities that take a C-string as input (e.g. Rf_reEnc()) accept NULL and propagate it. Of course these things can be modified to be consistent with the new "NULL pointer == NA" paradigm but this might end up being a bigger move than what it seems at first sight... Cheers, H. On 05/25/2016 08:43 AM, luke-tierney at uiowa.edu wrote:> On Wed, 25 May 2016, Tim Keitt wrote: > >> On Wed, May 25, 2016 at 7:22 AM, Michael Lawrence >> <lawrence.michael at gene.com >>> wrote: >> >>> On Wed, May 25, 2016 at 4:23 AM, Jeroen Ooms <jeroen.ooms at 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 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 at r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> >-- Herv? Pag?s Program in Computational Biology Division of Public Health Sciences Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N, M1-B514 P.O. Box 19024 Seattle, WA 98109-1024 E-mail: hpages at fredhutch.org Phone: (206) 667-5791 Fax: (206) 667-1319