Skip to content

Rubbish values written with zero-length vectors (PR#14217)

4 messages · g.russell at eos-solutions.com, Henrik Bengtsson, Peter Dalgaard +1 more

#
Full_Name: George Russell
Version: 2.10.0, 2.11.0 (2009-12-13 r50716)
OS: Windows
Submission from: (NULL) (217.111.3.131)


R trace:
-- cut here --
[1] 20522144
[1] 4.254131e-314
R version 2.10.0 (2009-10-26) 
i386-pc-mingw32 

locale:
[1] LC_COLLATE=German_Germany.1252  LC_CTYPE=German_Germany.1252   
[3] LC_MONETARY=German_Germany.1252 LC_NUMERIC=C                   
[5] LC_TIME=German_Germany.1252    

attached base packages:
[1] stats     graphics  grDevices datasets  utils     methods   base     
-- cut here --
Clearly the assignments v[[1]] <- v do not do anything useful, the problem is I
don't understand where the strange values left in v come from.

The same problem occurs with the 2.11.0 release r50716 and --vanilla. For
vanilla in Windows CMD mode I get different values in v, but ones which are to
me equally strange.

Many thanks for your help!

George Russell
1 day later
#
Confirmed behavior on R version 2.10.1 Patched (2010-01-12 r50990) and
R version 2.11.0 Under development (unstable) (2010-02-14 r51138)
[Windows Vista]:

INTEGERS:
[1] 0 0 0 0 0
[1]       0 2892960       0       0       0
[1]       0 2892960       0 2892960       0
int [1:5] 0 2892960 0 2892960 0

DOUBLES:
[1] 0 0 0 0 0
[1]       0 2892960       0       0       0
[1]       0 2892960       0 2892960       0
str [1:5] 0 2892960 0 2892960 0
[1]  0.000000e+00  3.487453e+07  0.000000e+00  3.487453e+07 4.261222e-314
num [1:5] 0.00 3.49e+07 0.00 3.49e+07 4.26e-314

The actual "rubbish" values are the same within each R session, but
differ between R sessions.

Certain looks like stray memory cells are assigned.

Wanted behavior should probably be:
Error in u[[5]] <- double(0) : replacement has length zero

cf. u[5] <- double(0) and
Error in u[[5]] <- double(5) :
  more elements supplied than there are to replace

/Henrik
On Fri, Feb 19, 2010 at 1:45 PM, <g.russell at eos-solutions.com> wrote:
#
g.russell at eos-solutions.com wrote:
You don't want to understand, believe me! ;-)

It's a bug, probably not the very worst kind, but accessing memory that 
isn't yours is potentially harmful (but writing to it is considerably 
worse).

Looks like the issue only concerns the right hand side; nothing to do 
with the auto-expansion of v. I also get

 > v <- integer(0)
 > u <- integer(1)
 > u[[2]] <-v
 > u
[1]         0 142000760
 > u[[1]] <-v
 > u
[1] 142000760 142000760
 > a <- 1
 > a[[1]] <-v
 > a
[1] 142000760

  
    
#
On 2/20/10 7:50 AM, Peter Dalgaard wrote:
I'm thinking this should be an error.  Similar to:
Error in v[[1]] = integer(3) :
  more elements supplied than there are to replace

But instead not enough elements supplied.  Perhaps:
Error in v[[1]] = integer() : [[ ]] replacement has zero length

The code in do_subassign2_dflt currently does not check that the
replacement has length > 0 for the nsubs == 1 case.  I think we want:


@@ -1529,6 +1532,8 @@ do_subassign2_dflt(SEXP call, SEXP op, SEXP args,
SEXP rho)
        if (nsubs == 0 || CAR(subs) == R_MissingArg)
            error(_("[[ ]] with missing subscript"));
        if (nsubs == 1) {
+            if (length(y) == 0)
+                error(_("[[ ]] replacement has zero length"));
            offset = OneIndex(x, thesub, length(x), 0, &newname,
recursed ? len-1 : -1, R_NilValue);
            if (isVectorList(x) && isNull(y)) {
                x = DeleteOneVectorListItem(x, offset);


+ seth