[Rd] Suggestion: mkString(NULL) should be NA

[Hervé Pagès]

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