Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Herve Pages
Peter Dalgaard wrote:
> Herve Pages wrote:
[...]
>> So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(),
>> SET_NAMES(), etc... can't (and will never) trigger garbage collection.
>> But what about defineVar()? More generally, how do I know this for the
>> functions/macros listed in Rdefines.h and Rinternals.h?
>>  
> Yes, that point was well taken. You can't know unless we write it
> somewhere. You can read the sources, but that is no guarantee that it
> won't change in future versions. We should be better at documenting that
> stuff, if for no other reason then to be able to distinguish between
> YOUR bugs and OUR bugs.
> If you grep through the sources, you'll find a number of instances of
> things like
> 
> defineVar(name, mkPromise(...), ...)
> 
> which would break along with your case, but that is of course only an
> indication, not proof that you can actually leave the value unprotected.
> 

Agreed. Thanks for your reply!

H.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Peter Dalgaard
Herve Pages wrote:
> Peter Dalgaard wrote:
>>
>> That's not the problem you raised (argument evaluation order), but
>> there's a CONS inside defineVar, and as far as I can see, it doesn't
>> protect its arguments, so you could well be right.
>> 
>
> This problem is related to my original problem since it would cause the same
> disaster: garbage collection on my unprotected SEXP.
>   
Sure, I just wasn't looking there because you told me to look elsewhere

> The more general problem I'm facing is to know whether or not it is safe to
> use a function like mkans() (that returns an unprotected SEXP) like this:
>
>   SET_ELEMENT(ans, 0, mkans(x));
>
> In the case of SET_ELEMENT() or SET_STRING_ELT() it seems to be safe. For
> example I've seen this
>
>   SET_STRING_ELT(ans, 0, mkChar(buf));
>
> in many places. So I'm using it too, even if the SEXP returned by mkChar()
> is not protected.
> Same here:
>
>   SET_ELEMENT(ans, 0, duplicate(x));
>
> The SEXP returned by duplicate() is not protected.
>
> So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(),
> SET_NAMES(), etc... can't (and will never) trigger garbage collection.
> But what about defineVar()? More generally, how do I know this for the
> functions/macros listed in Rdefines.h and Rinternals.h?
>   
>
Yes, that point was well taken. You can't know unless we write it 
somewhere. You can read the sources, but that is no guarantee that it 
won't change in future versions. We should be better at documenting that 
stuff, if for no other reason then to be able to distinguish between 
YOUR bugs and OUR bugs. 

If you grep through the sources, you'll find a number of instances of 
things like

defineVar(name, mkPromise(...), ...)

which would break along with your case, but that is of course only an 
indication, not proof that you can actually leave the value unprotected.

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Herve Pages
Peter Dalgaard wrote:
> Herve Pages wrote:
>> Hi Peter,
>>
>> Peter Dalgaard wrote:
>>   
>>> Herve Pages wrote:
>>> 
 Hi,

 I'm wondering if this code from the "Writing R Extensions" manual
 is really safe:

  SEXP mkans(double x)
  {
  SEXP ans;
  PROTECT(ans = allocVector(REALSXP, 1));
  REAL(ans)[0] = x;
  UNPROTECT(1);
  return ans;
  }

  double feval(double x, SEXP f, SEXP rho)
  {
  defineVar(install("x"), mkans(x), rho);
  return(REAL(eval(f, rho))[0]);
  }

 In C, the order in which function arguments are evaluated before the
 function itself is called is undefined. Hence there is no guarantee
 that install("x") will be evaluated before mkans(x). What happens if
 mkans(x) is evaluated first? Then install("x") will be called and
 eventually trigger garbage collection while the SEXP returned by
 mkans(x) is still unprotected.

 I'm asking because I'm getting all sorts of problems with

   defineVar(install(somekey), mkans(x), rho);

 In my code this line is inside a big loop (hundred of thousands of
 iterations) so I end up with a lot of symbols in the rho environment.

 The problems I've seen are hard to reproduce: sometimes it's a segfault,
 sometimes a "cons memory exhausted" error, or sometimes everything looks
 fine except that, later, when I retrieve values from the rho environment
 with findVar(), some of them are altered!

 But if I replace the above line by:

   PROTECT(ans = mkans(x));
   defineVar(install(somekey), ans, rho);
   UNPROTECT(1);

 then everything works fine :-)

   
   
>>> Sounds like you are right. You don't really have the "smoking gun", but
>>> it doesn't seem to be worth trying to catch the actual bug in action
>>> with hardware watchpoints and whatnot.
>>>
>>> The opposite fix should work too (does it?):
>>>
>>> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);}
>>> 
>> So now you are protected against install(somekey) eventually triggering
>> garbage collection but you are still not protected against defineVar() itself
>> triggering garbage collection. Maybe defineVar() does not do that, and will
>> never do it, but isn't it risky to rely on this kind of assumption?
>>
>> Thanks!
>> H.
>>   
> That's not the problem you raised (argument evaluation order), but
> there's a CONS inside defineVar, and as far as I can see, it doesn't
> protect its arguments, so you could well be right.

This problem is related to my original problem since it would cause the same
disaster: garbage collection on my unprotected SEXP.
The more general problem I'm facing is to know whether or not it is safe to
use a function like mkans() (that returns an unprotected SEXP) like this:

  SET_ELEMENT(ans, 0, mkans(x));

In the case of SET_ELEMENT() or SET_STRING_ELT() it seems to be safe. For
example I've seen this

  SET_STRING_ELT(ans, 0, mkChar(buf));

in many places. So I'm using it too, even if the SEXP returned by mkChar()
is not protected.
Same here:

  SET_ELEMENT(ans, 0, duplicate(x));

The SEXP returned by duplicate() is not protected.

So everybody seems to assume that SET_ELEMENT(), SET_STRING_ELT(),
SET_NAMES(), etc... can't (and will never) trigger garbage collection.
But what about defineVar()? More generally, how do I know this for the
functions/macros listed in Rdefines.h and Rinternals.h?

Thanks!
H.

> 
>>   
>>> (I don't think you need to  PROTECT elements in the symbol table)
>>>
>>> 
>>   
> 
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Just-in-time compiler for R

2008-01-16 Thread Stephen Milborrow
Greetings R developers!

I have been working on a just-in-time compiler for R arithmetic expressions.
An example:


jit(1)   # turn on just-in-time compilation
for(i in 1:na)# example convolution code
for(j in 1:nb)
  ab[i + j] <- ab[i + j] + a[i] * b[j]


The loop will run about 30% faster. That's not much of a speedup, but the
code is still in early development and the figure will get much better.

If you are interested there is more information at
www.milbo.users.sonic.net/ra.




Stephen Milborrow
www.milbo.users.sonic.net

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Peter Dalgaard
Luke Tierney wrote:
> On Wed, 16 Jan 2008, Peter Dalgaard wrote:
>
>> Herve Pages wrote:
>> Hi Peter,
>>
>> Peter Dalgaard wrote:
>>
>>> Herve Pages wrote:
>>>
 Hi,

 I'm wondering if this code from the "Writing R Extensions" manual
 is really safe:

  SEXP mkans(double x)
  {
  SEXP ans;
  PROTECT(ans = allocVector(REALSXP, 1));
  REAL(ans)[0] = x;
  UNPROTECT(1);
  return ans;
  }

  double feval(double x, SEXP f, SEXP rho)
  {
  defineVar(install("x"), mkans(x), rho);
  return(REAL(eval(f, rho))[0]);
  }

 In C, the order in which function arguments are evaluated before the
 function itself is called is undefined. Hence there is no guarantee
 that install("x") will be evaluated before mkans(x). What happens if
 mkans(x) is evaluated first? Then install("x") will be called and
 eventually trigger garbage collection while the SEXP returned by
 mkans(x) is still unprotected.

 I'm asking because I'm getting all sorts of problems with

   defineVar(install(somekey), mkans(x), rho);

 In my code this line is inside a big loop (hundred of thousands of
 iterations) so I end up with a lot of symbols in the rho environment.

 The problems I've seen are hard to reproduce: sometimes it's a
 segfault,
 sometimes a "cons memory exhausted" error, or sometimes everything
 looks
 fine except that, later, when I retrieve values from the rho
 environment
 with findVar(), some of them are altered!

 But if I replace the above line by:

   PROTECT(ans = mkans(x));
   defineVar(install(somekey), ans, rho);
   UNPROTECT(1);

 then everything works fine :-)



>>> Sounds like you are right. You don't really have the "smoking gun", but
>>> it doesn't seem to be worth trying to catch the actual bug in action
>>> with hardware watchpoints and whatnot.
>>>
>>> The opposite fix should work too (does it?):
>>>
>>> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);}
>>>
>>
>> So now you are protected against install(somekey) eventually triggering
>> garbage collection but you are still not protected against
>> defineVar() itself
>> triggering garbage collection. Maybe defineVar() does not do that,
>> and will
>> never do it, but isn't it risky to rely on this kind of assumption?
>>
>> Thanks!
>> H.
>>
> That's not the problem you raised (argument evaluation order), but
> there's a CONS inside defineVar, and as far as I can see, it doesn't
> protect its arguments, so you could well be right.

> CONS itself protects its arguments though.
>
> luke
>
Ah, right! (and one of them is "value"). That explains why we haven't
seen crashes left right and center from this

How about the hashed environment case? R_Newhashpjw and R_HashSet
wouldn't need allocation, and R_HashResize is after the assignment, so I
suppose it is OK.

We should make this sort ot convention more explicit somehow.


-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Luke Tierney

On Wed, 16 Jan 2008, Peter Dalgaard wrote:


Herve Pages wrote:
Hi Peter,

Peter Dalgaard wrote:


Herve Pages wrote:


Hi,

I'm wondering if this code from the "Writing R Extensions" manual
is really safe:

 SEXP mkans(double x)
 {
 SEXP ans;
 PROTECT(ans = allocVector(REALSXP, 1));
 REAL(ans)[0] = x;
 UNPROTECT(1);
 return ans;
 }

 double feval(double x, SEXP f, SEXP rho)
 {
 defineVar(install("x"), mkans(x), rho);
 return(REAL(eval(f, rho))[0]);
 }

In C, the order in which function arguments are evaluated before the
function itself is called is undefined. Hence there is no guarantee
that install("x") will be evaluated before mkans(x). What happens if
mkans(x) is evaluated first? Then install("x") will be called and
eventually trigger garbage collection while the SEXP returned by
mkans(x) is still unprotected.

I'm asking because I'm getting all sorts of problems with

  defineVar(install(somekey), mkans(x), rho);

In my code this line is inside a big loop (hundred of thousands of
iterations) so I end up with a lot of symbols in the rho environment.

The problems I've seen are hard to reproduce: sometimes it's a segfault,
sometimes a "cons memory exhausted" error, or sometimes everything looks
fine except that, later, when I retrieve values from the rho environment
with findVar(), some of them are altered!

But if I replace the above line by:

  PROTECT(ans = mkans(x));
  defineVar(install(somekey), ans, rho);
  UNPROTECT(1);

then everything works fine :-)




Sounds like you are right. You don't really have the "smoking gun", but
it doesn't seem to be worth trying to catch the actual bug in action
with hardware watchpoints and whatnot.

The opposite fix should work too (does it?):

{ SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);}



So now you are protected against install(somekey) eventually triggering
garbage collection but you are still not protected against defineVar() itself
triggering garbage collection. Maybe defineVar() does not do that, and will
never do it, but isn't it risky to rely on this kind of assumption?

Thanks!
H.


That's not the problem you raised (argument evaluation order), but
there's a CONS inside defineVar, and as far as I can see, it doesn't
protect its arguments, so you could well be right.

CONS itself protects its arguments though.

luke




(I don't think you need to  PROTECT elements in the symbol table)








--
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:  [EMAIL PROTECTED]
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Peter Dalgaard
Herve Pages wrote:
> Hi Peter,
>
> Peter Dalgaard wrote:
>   
>> Herve Pages wrote:
>> 
>>> Hi,
>>>
>>> I'm wondering if this code from the "Writing R Extensions" manual
>>> is really safe:
>>>
>>>  SEXP mkans(double x)
>>>  {
>>>  SEXP ans;
>>>  PROTECT(ans = allocVector(REALSXP, 1));
>>>  REAL(ans)[0] = x;
>>>  UNPROTECT(1);
>>>  return ans;
>>>  }
>>>
>>>  double feval(double x, SEXP f, SEXP rho)
>>>  {
>>>  defineVar(install("x"), mkans(x), rho);
>>>  return(REAL(eval(f, rho))[0]);
>>>  }
>>>
>>> In C, the order in which function arguments are evaluated before the
>>> function itself is called is undefined. Hence there is no guarantee
>>> that install("x") will be evaluated before mkans(x). What happens if
>>> mkans(x) is evaluated first? Then install("x") will be called and
>>> eventually trigger garbage collection while the SEXP returned by
>>> mkans(x) is still unprotected.
>>>
>>> I'm asking because I'm getting all sorts of problems with
>>>
>>>   defineVar(install(somekey), mkans(x), rho);
>>>
>>> In my code this line is inside a big loop (hundred of thousands of
>>> iterations) so I end up with a lot of symbols in the rho environment.
>>>
>>> The problems I've seen are hard to reproduce: sometimes it's a segfault,
>>> sometimes a "cons memory exhausted" error, or sometimes everything looks
>>> fine except that, later, when I retrieve values from the rho environment
>>> with findVar(), some of them are altered!
>>>
>>> But if I replace the above line by:
>>>
>>>   PROTECT(ans = mkans(x));
>>>   defineVar(install(somekey), ans, rho);
>>>   UNPROTECT(1);
>>>
>>> then everything works fine :-)
>>>
>>>   
>>>   
>> Sounds like you are right. You don't really have the "smoking gun", but
>> it doesn't seem to be worth trying to catch the actual bug in action
>> with hardware watchpoints and whatnot.
>>
>> The opposite fix should work too (does it?):
>>
>> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);}
>> 
>
> So now you are protected against install(somekey) eventually triggering
> garbage collection but you are still not protected against defineVar() itself
> triggering garbage collection. Maybe defineVar() does not do that, and will
> never do it, but isn't it risky to rely on this kind of assumption?
>
> Thanks!
> H.
>   
That's not the problem you raised (argument evaluation order), but
there's a CONS inside defineVar, and as far as I can see, it doesn't
protect its arguments, so you could well be right.

>   
>> (I don't think you need to  PROTECT elements in the symbol table)
>>
>> 
>
>   


-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Herve Pages
Hi Peter,

Peter Dalgaard wrote:
> Herve Pages wrote:
>> Hi,
>>
>> I'm wondering if this code from the "Writing R Extensions" manual
>> is really safe:
>>
>>  SEXP mkans(double x)
>>  {
>>  SEXP ans;
>>  PROTECT(ans = allocVector(REALSXP, 1));
>>  REAL(ans)[0] = x;
>>  UNPROTECT(1);
>>  return ans;
>>  }
>>
>>  double feval(double x, SEXP f, SEXP rho)
>>  {
>>  defineVar(install("x"), mkans(x), rho);
>>  return(REAL(eval(f, rho))[0]);
>>  }
>>
>> In C, the order in which function arguments are evaluated before the
>> function itself is called is undefined. Hence there is no guarantee
>> that install("x") will be evaluated before mkans(x). What happens if
>> mkans(x) is evaluated first? Then install("x") will be called and
>> eventually trigger garbage collection while the SEXP returned by
>> mkans(x) is still unprotected.
>>
>> I'm asking because I'm getting all sorts of problems with
>>
>>   defineVar(install(somekey), mkans(x), rho);
>>
>> In my code this line is inside a big loop (hundred of thousands of
>> iterations) so I end up with a lot of symbols in the rho environment.
>>
>> The problems I've seen are hard to reproduce: sometimes it's a segfault,
>> sometimes a "cons memory exhausted" error, or sometimes everything looks
>> fine except that, later, when I retrieve values from the rho environment
>> with findVar(), some of them are altered!
>>
>> But if I replace the above line by:
>>
>>   PROTECT(ans = mkans(x));
>>   defineVar(install(somekey), ans, rho);
>>   UNPROTECT(1);
>>
>> then everything works fine :-)
>>
>>   
> Sounds like you are right. You don't really have the "smoking gun", but
> it doesn't seem to be worth trying to catch the actual bug in action
> with hardware watchpoints and whatnot.
> 
> The opposite fix should work too (does it?):
> 
> { SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);}

So now you are protected against install(somekey) eventually triggering
garbage collection but you are still not protected against defineVar() itself
triggering garbage collection. Maybe defineVar() does not do that, and will
never do it, but isn't it risky to rely on this kind of assumption?

Thanks!
H.

> 
> (I don't think you need to  PROTECT elements in the symbol table)
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] data types / numerative system

2008-01-16 Thread Prof Brian Ripley
On Wed, 16 Jan 2008, Duncan Murdoch wrote:

> On 1/16/2008 10:30 AM, [EMAIL PROTECTED] wrote:
>> hello all,
>>
>> well it is a general question, surely this is written somewhere but I cannot 
>> find it.
>> where is the full list of 'shortcuts' for numerative systems?
>> (so 0x123 : hex, 123L : dec(?... or is it for a... long datatype?))
>> are there in R 'shortcuts' for data types?
>
> You want to look in the section on "Constants" of the R Language
> References (Section 3.1.1 in the PDF version in 2.6.1).

Or ?NumericConstants, linked from ?Syntax.  (The online help tends to be 
more up-to-date then that _draft_ reference manual.)

>
> In summary:  the 0x prefix indicates hex, the L suffix indicates the
> integer type.
>
> Duncan Murdoch
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] data types / numerative system

2008-01-16 Thread Duncan Murdoch
On 1/16/2008 10:30 AM, [EMAIL PROTECTED] wrote:
> hello all,
> 
> well it is a general question, surely this is written somewhere but I cannot 
> find it.
> where is the full list of 'shortcuts' for numerative systems?
> (so 0x123 : hex, 123L : dec(?... or is it for a... long datatype?))
> are there in R 'shortcuts' for data types?

You want to look in the section on "Constants" of the R Language 
References (Section 3.1.1 in the PDF version in 2.6.1).

In summary:  the 0x prefix indicates hex, the L suffix indicates the 
integer type.

Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] data types / numerative system

2008-01-16 Thread AlexanderP
hello all,

well it is a general question, surely this is written somewhere but I cannot 
find it.
where is the full list of 'shortcuts' for numerative systems?
(so 0x123 : hex, 123L : dec(?... or is it for a... long datatype?))
are there in R 'shortcuts' for data types?

thanks,
Alex
-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] %s in filename when opening device causes crash (PR#10571)

2008-01-16 Thread Prof Brian Ripley
On Wed, 16 Jan 2008, Richard Cotton wrote:

>
>
>
> Prof Brian Ripley wrote:
>>
>>> Yes. The problem is of course that we do want a sprintf() format there
>>> for "Rplot%03d.pdf" et al. One  option would be to escape "%" except
>>> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible.
>>
>> But there are other integer formats (%i, %u, %x, %X), and other flags (#
>> might be useful).  So the list of valid inputs is also rather long.  It
>> would be tedious to do at C level, but a check in the R-level wrapper
>> would be easier (if not 'simple').
>>
>
> Having just worked my way through the alphabet, I can say that it is only
> the letters 's' and 'n' that cause any problems.  Thus, if you do decide to
> handle the error in the R wrapper functions, the regex for bad inputs is
> fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]".

Thanks: but %% (escaped %) should be allowed (and only ASCII blank is 
allowed as a flag, and only ASCII digits).

We decided to do the opposite and test for an allowed format
(you are only allowed to have one).  So the current check is

### Check for a single valid integer format
checkIntFormat <- function(s)
{
 ## OK if no unescaped %, so first remove those
 s <- gsub("%%", "", s)
 if(length(grep("%", s)) == 0) return(TRUE)
 ## now remove at most one valid(ish) integer format
 s <- sub("%[#0 +-]*[0-9.]*[diouxX]", "", s)
 length(grep("%", s)) == 0
}

The set of flags is debatable, and not yet final.  Not all strings that 
pass that test are valid formats, but hopefully the exceptions are

- rare
- will not crash R.

Empirical testing of crashing is not comprehensive and machine-dependent 
even if you use a tool like valgrind to detect violations (32- vs 64-bit 
issues, for example).

Unfortunately there *is* a C-level call to the postscript driver, so some 
C-level checking is needed.

-- 
Brian D. Ripley,  [EMAIL PROTECTED]
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] %s in filename when opening device causes crash (PR#10571)

2008-01-16 Thread Peter Dalgaard
Richard Cotton wrote:
>
> Prof Brian Ripley wrote:
>   
>>> Yes. The problem is of course that we do want a sprintf() format there
>>> for "Rplot%03d.pdf" et al. One  option would be to escape "%" except
>>> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible.
>>>   
>> But there are other integer formats (%i, %u, %x, %X), and other flags (# 
>> might be useful).  So the list of valid inputs is also rather long.  It 
>> would be tedious to do at C level, but a check in the R-level wrapper 
>> would be easier (if not 'simple').
>>
>> 
>
> Having just worked my way through the alphabet, I can say that it is only
> the letters 's' and 'n' that cause any problems.  Thus, if you do decide to
> handle the error in the R wrapper functions, the regex for bad inputs is
> fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]".
>   
Not quite. The floating point formats are also problematic; you may
fetch 8 bytes where only 4 was allocated. Also, %%s should not be
forbidden. Anyways, I believe Brian has this in hand.

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] %s in filename when opening device causes crash (PR#10571)

2008-01-16 Thread Richard Cotton



Prof Brian Ripley wrote:
> 
>> Yes. The problem is of course that we do want a sprintf() format there
>> for "Rplot%03d.pdf" et al. One  option would be to escape "%" except
>> when in (regexp) "%[0-9]*d", which seems nontrivial, but not impossible.
> 
> But there are other integer formats (%i, %u, %x, %X), and other flags (# 
> might be useful).  So the list of valid inputs is also rather long.  It 
> would be tedious to do at C level, but a check in the R-level wrapper 
> would be easier (if not 'simple').
> 

Having just worked my way through the alphabet, I can say that it is only
the letters 's' and 'n' that cause any problems.  Thus, if you do decide to
handle the error in the R wrapper functions, the regex for bad inputs is
fairly straightforward "%[#[:blank:]\\+\\-]*[[:digit:]]*[sn]".
-- 
View this message in context: 
http://www.nabble.com/-s-in-filename-when-opening-device-causes-crash-%28PR-10571%29-tp14806982p14877649.html
Sent from the R devel mailing list archive at Nabble.com.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Pb with defineVar() example in the "Writing R Extensions" manual

2008-01-16 Thread Peter Dalgaard
Herve Pages wrote:
> Hi,
>
> I'm wondering if this code from the "Writing R Extensions" manual
> is really safe:
>
>  SEXP mkans(double x)
>  {
>  SEXP ans;
>  PROTECT(ans = allocVector(REALSXP, 1));
>  REAL(ans)[0] = x;
>  UNPROTECT(1);
>  return ans;
>  }
>
>  double feval(double x, SEXP f, SEXP rho)
>  {
>  defineVar(install("x"), mkans(x), rho);
>  return(REAL(eval(f, rho))[0]);
>  }
>
> In C, the order in which function arguments are evaluated before the
> function itself is called is undefined. Hence there is no guarantee
> that install("x") will be evaluated before mkans(x). What happens if
> mkans(x) is evaluated first? Then install("x") will be called and
> eventually trigger garbage collection while the SEXP returned by
> mkans(x) is still unprotected.
>
> I'm asking because I'm getting all sorts of problems with
>
>   defineVar(install(somekey), mkans(x), rho);
>
> In my code this line is inside a big loop (hundred of thousands of
> iterations) so I end up with a lot of symbols in the rho environment.
>
> The problems I've seen are hard to reproduce: sometimes it's a segfault,
> sometimes a "cons memory exhausted" error, or sometimes everything looks
> fine except that, later, when I retrieve values from the rho environment
> with findVar(), some of them are altered!
>
> But if I replace the above line by:
>
>   PROTECT(ans = mkans(x));
>   defineVar(install(somekey), ans, rho);
>   UNPROTECT(1);
>
> then everything works fine :-)
>
>   
Sounds like you are right. You don't really have the "smoking gun", but
it doesn't seem to be worth trying to catch the actual bug in action
with hardware watchpoints and whatnot.

The opposite fix should work too (does it?):

{ SEXP sym = install(somekey) ; defineVar(sym, mkans(x), rho);}

(I don't think you need to  PROTECT elements in the symbol table)

-- 
   O__   Peter Dalgaard Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark  Ph:  (+45) 35327918
~~ - ([EMAIL PROTECTED])  FAX: (+45) 35327907

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel