From simon.urbanek at r-project.org  Wed Jun  8 20:23:29 2011
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Wed, 8 Jun 2011 14:23:29 -0400
Subject: [Rd] "warning: assignment discards qualifiers from pointer
	target type"
In-Reply-To: <20110608160839.GA11746@siouxsie>
References: <20110607130854.GA4510@siouxsie> <4DEE3786.5000800@gmail.com>
	<alpine.LFD.2.02.1106071606010.26985@gannet.stats.ox.ac.uk>
	<20110608160839.GA11746@siouxsie>
Message-ID: <B68723F7-F66B-40FD-AE38-0A88C0C51B82@r-project.org>


On Jun 8, 2011, at 12:08 PM, oliver wrote:

> On Wed, Jun 08, 2011 at 12:22:10PM +0100, Prof Brian Ripley wrote:
>> On Tue, 7 Jun 2011, Duncan Murdoch wrote:
>> 
>>> On 07/06/2011 9:08 AM, oliver wrote:
>>>> Hello,
>>>> 
>>>> following an advice here from the list I looked into sources of other
>>>> packages (xts) and found the TYPEOF() macro/function, which really is
>>>> helpful.
>> 
>> It is documented, of course, but actually better alternatives are
>> described in 'Writing R Extensions'.
>> 
>> We would urge you to study the R sources rather than copy bad habits
>> from randomly chosen package sources.
> [...]
> 
> Hmhh, it was not randomly chosen, it was, what I got as a hint here on the list.
> 

It was not provided to you to look at how it checks arguments. For basic usage it's better to look at the R code. The coding styles vary a lot in packages (and so does the quality of packages) - some of them are really bad, but you have to remember that most people write packages in their free time and are not programmers...


> 
>> 
>>>> I iused the follwong code snippet:
>>>> 
>>>> 
>>>>  switch( TYPEOF( filename_sexp ) )
>>>>  {
>>>>        case STRSXP: filename = CHAR( STRING_ELT(filename_sexp, 0) );
>>>>                     break;
>>>> 
>>>>        default:     error("filename argument must be a string");
>>>>                     break;
>>>>  }
>>>> 
>>>> 
>>>> Here, filename is of type char*
>>>> and one function opens a file with that name.
>>>> So it is purely intended to just grab out the char* from the
>>>> String-Expression.
>>>> 
>>>> Am I doing something wrong here, or is it ok, but I have somehow
>>>> to say the extracting macros/functions, that it is really intended
>>>> to throw away information and that a warning is not necessary?
>>> 
>>> The result of calling CHAR should be a "const char *".  You are
>>> not allowed to touch the string it points to.
>> 
>> Note too that isString() exists for this purpose,
> [...]
> 
> OK, I also sometimes used that (maybe I threw it out or used it in other
> modules).
> 
> 
> 
>> and there is no
>> check in that code that LENGTH(filename_sexp) > 0 (or == 1).  In the
>> R sources you will often see things like
>> 
>>    if(!isString(sfile) || LENGTH(sfile) < 1)
>>        error("invalid '%s' argument", "description");
> [...]
> 
> If it's a vector, I can just pic the first element.

Yes, but only if it's not a vector of length zero - hence the necessary check.


> Or does   LENGTH(sfile)  give the length of the string itself
> (like strlen(3))?
> 

No.


> If the latter, then my file-opeing operation would faile with an error.
> Of course I check if my fopen() gibves back NULL.
> 
> 
> 
>> 
>> Then, reading on,
>> 
>>    file = translateChar(STRING_ELT(sfile, 0));
> 
> translateChar is explained on page 120 of the extension writing do.
> 
> I'm not in this point of the documentation.
> 
> And I often need to look around, when I want to find a function,
> as they are documented/explained somewhere during the flow of the text.
> 
> Something like a API description that is brief would help.
> 
> For example something like in the manuals of the OCaml language:
> 
>  http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html
> 
> 
> That's very brief.
> 
> Chapter 6 of the  "Writing R Extensions" is rather in this style
> and gives a good overview.
> Something like that for the macros would be helpful.
> 
> 
>> 
>> for you cannot (in general) assume that the character vector passed
>> is in the native encoding.
> 
> I try to do some coercions (e.g. as.integer())
> when I need integer in the C-code and then
> in the C-part rigidly check on integer.
> 

It's usually more efficient to use coerceVector() on the C side since that guarantees no copy is made for matching types (this matters for passing data, not so much for passing arguments). You can do either - check on R side or check on C side, usually you don't need both (but you certainly can).

Cheers,
Simon


> About the char-encodings I have not thought much.
> 
> 
> Ciao,
>   Oliver
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> 



[Rd] "warning: assignment discards qualifiers from pointer target type"
Simon Urbanek