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

[oliver]

On Thu, Jun 09, 2011 at 12:56:09PM -0400, Simon Urbanek wrote:
> 
> On Jun 9, 2011, at 11:15 AM, oliver wrote:
> 
> > On Thu, Jun 09, 2011 at 10:54:28AM -0400, Duncan Murdoch wrote:
> >> On 09/06/2011 9:28 AM, oliver wrote:
> >>> On Thu, Jun 09, 2011 at 07:43:20AM -0400, Duncan Murdoch wrote:
> >>>> On 11-06-09 7:27 AM, oliver wrote:
> >>>>> On Wed, Jun 08, 2011 at 08:35:34PM -0400, Simon Urbanek wrote:
> >>>>>> 
> >>>>>> On Jun 8, 2011, at 8:32 PM, oliver wrote:
> >>>>>> 
> >>>>>>> On Thu, Jun 09, 2011 at 02:17:31AM +0200, oliver wrote:
> >>>>>>> [...]
> >>>>>>>> OK, I looked at this now.
> >>>>>>>> 
> >>>>>>>> LENGTH() checks the length of the vector.
> >>>>>>>> 
> >>>>>>>> Good to know this.
> >>>>>>>> 
> >>>>>>>> So the problem of a vector of length 0 can be with any arguments of type SEXP,
> >>>>>>>> hence I will need to check ANY arg on it's length.
> >>>>>>>> 
> >>>>>>>> This is vital to stability under any situation.
> >>>>>>>> 
> >>>>>>>> Thanks for this valuable hint!
> >>>>>>>> 
> >>>>>>>> I will add checks for all my SEXP-args.
> >>>>>>> [...]
> >>>>>>> 
> >>>>>>> Hey, LENGTH() does not work with String-vectors! :(
> >>>>>>> 
> >>>>>> 
> >>>>>> Of course it does ...
> >>>>>> 
> >>>>>> 
> >>>>> 
> >>>>> It does not so on my R 2.10.1 installation.
> >>>>> 
> >>>>> 
> >>>>> In the R-Shell I get:
> >>>>> 
> >>>>>   ==============================
> >>>>>>  length(c())
> >>>>>   [1] 0
> >>>>>> 
> >>>>>   ==============================
> >>>>> 
> >>>>> So c() is vec of length 0.
> >>>>> 
> >>>>> When I feed my readjpeg() with c() as filename arg,
> >>>>> 
> >>>>> testing with:
> >>>>> ====================================================
> >>>>>   if( LENGTH( filename_sexp )<   1 )
> >>>>>   {
> >>>>>     error("LENGTH( filename_sexp )<   1");
> >>>>>     //error("filename can't be vector of length 0");
> >>>>>   }
> >>>>>   else
> >>>>>   {
> >>>>>     error("LENGTH( filename_sexp ) is not<   1");
> >>>>>   }
> >>>>> ====================================================
> >>>>> 
> >>>>> 
> >>>>> I got:
> >>>>>   Error in readjpeg(filename = c()) : LENGTH( filename_sexp ) is not<   1
> >>>>> 
> >>>>> 
> >>>>> You can explain why?
> >>>> 
> >>>> c() doesn't create a STRSXP, it is NULL, which is a NILSXP.
> >>>> LENGTH() doesn't work on that object.  (I'd recommend using length()
> >>>> rather than LENGTH(); it's a function, not a macro, and it does give
> >>>> the expected answer.)
> >>> [...]
> >>> 
> >>> Interestingly, c() as value for an integer value
> >>> can be testes correctly with LENGTH().
> >> 
> >> Presumably you converted it to an INTSXP.  c() is NULL.
> > [...]
> > 
> > Ooops, yes. In the R-part. :-)
> > I did it, because when I don't get an int from the user's call,
> > I have set it to NA (default in the R-function definition).
> > 
> > I made
> >  width <- as.integer(width)
> > for easy check inside the C-part, on integer.
> > 
> > (I really only need int, no floating point values.)
> > 
> > I thought this makes the C-code easier at that part.
> > 
> > Or I may check on NA inside the C-part.
> > 
> > How would I do that correctly?
> > 
> > After so much different opinions I read here, I'm rather puzzled on that now.
> > 
> > If there is already a R-extensions-FAQ I could collect the informations
> > from the mail sof the last days, so that the different opinions and the discussion
> > can result in a some answers...
> > 
> 
> So far you were creating the confusion, the facts are fairly simple if you
> have some clue about C and R. I would like to ask you to, please, read and
> understand C standard and R-exts *before* posting further questions since it's
> pointless if we provide answers that you don't understand.
[...]

I understand the answers if it's about C, but I'm new to R.
If you think I did wrote something about C, that is not correct,
please show me.


On the R-usage: Regarding the LENGTH() vs. length(),
both are used in the examples of "Writing R Extensions"
and somewhere it was mentioned that either macros or functions can be used.

Here on the  list I read different opinions about that, coming from  different people.
As there are also different usages in the "Writing R Extensions" it's confusing.

Macro or function?
Should I include Rinternals.h or Rdefines.h?

It's not clear, what I should prefer, or when.



> The fact that you
> are impatient (as you said yourself) doesn't entitle you to waste other
> people's time to explain things to you while you are unwilling to take the time
> yourself.


That the memory allocation part was coming in chapter six,
which at first glance rather looked like a reference of convenience or mathematical
functions that can be called, I didn't awaited.
(And so I missed it in chapter 5, hence my questions.)

So I just can apologize that I didn't read that before asking,
but also can mention that the memory allocation issue also might make sense to be
mentioned in chapter 5.

And on the other hand I think "wasting time of others" makes no sense.
I also would invest time to help others on topics, even it might be documented
somewhere. (Thats why there are mailing lists, IMHO.)
It could even be the case that people read something but didn't remember
anything after first reading.

For example I had to look at the "Writing R extensions" more than once,
and some things I already read, I had not saved immediately.
(That's normal, that people need repitition to learn, btw.)

There always is a tradeoff between "first-read-long-documentations and do not practice"
and "read in the docs, try it out, read more, try it out" (and in between ask).

I learn things better with the second attempt.
And if the docs have a different direction in which things are explained,
questions arise during the process.

To answer them immediately will make people learn faster,
and IMHO this will pay back for the whole project,
in quality and quantity.

Some people here on the list mentioned some packages lacking
quality. This might in part be how people program, and in part also,
how (if) questions are answered (or not).



> If you have serious question beyond what is documented, feel free to
> ask, but make sure you have spent the time to think about it before you do so.

I will read further in the "Writing R Extensions", maybe some things there pop up
at pages, where I didn't expected it.
One question about error() already was answered now in section 6.2 (format strings
can be used like in printf(), or at least similar). (I was tempted to ask that too ;))


> 
> 
> >> 
> >>> So the question arises: is c() always creating NILSXP,
> >>> or is it NILSXP only for STRSXP, and 0 otherwise?
> >> 
> >> That question makes no sense at all.
> > 
> > It make sense for the picky.
> > As NULL is rather (void*)0  and a pointer is not an int (just can be coerced normally) ;)
> > 
> 
> It's not - you're confusing NULL in R with NULL in C.
[...]

I just don't know what is behind those macros.
Thats why I'm asking.... (or guessing).


> Both NILSXP and STRSXP are SEXP types - and obviously distinct ones. R will never return a null pointer for a SEXP.

As SEXP seems to be a general type, I would assume SEXP to be a union,
which can hold REALSXP, STRSXP, and some others.
(And NILSXP, which seem to be R-NULL, may or may not be C-NULL.)

But this is only an assumption.

Maybe it is necessary to read the R sources.
I normally think reading the sources might be interesting but not necessary.
And following the encapsulation issue and inteface-vs-implementation issue
(black box), IMHO it would be better if there is no necessity for "reading the sources". 

But maybe it is necessary.


Ciao,
   Oliver