search for: enlargevector

...this bug (like a function) Here's how the problem happens: 1. The call lands in src/main/subassign.c, do_subassign2_dflt(). 2. do_subassign2_dflt() calls SubassignTypeFix() to prepare the operand for the assignment. 3. Since the assignment is "stretching", SubassignTypeFix() calls EnlargeVector() to provide the space for the assignment. The bug relies on `x` not being IS_GROWABLE(), which may explain why a plain x[[4]] <- list() sometimes doesn't fail. The future assignment result `x` is now expression(a, b, c, NULL), and the old `x` set to expression(NULL, NULL, NULL) by SET_VE...

...s how the problem happens: > > 1. The call lands in src/main/subassign.c, do_subassign2_dflt(). > > 2. do_subassign2_dflt() calls SubassignTypeFix() to prepare the operand > for the assignment. > > 3. Since the assignment is "stretching", SubassignTypeFix() calls > EnlargeVector() to provide the space for the assignment. > > The bug relies on `x` not being IS_GROWABLE(), which may explain > why a plain x[[4]] <- list() sometimes doesn't fail. > > The future assignment result `x` is now expression(a, b, c, NULL), and > the old `x` set to expression(...

There seems to be a bug in out-of-bounds assignment of list objects to an expression() vector. Tested on release and devel. (Many thanks to folks over at Mastodon for the help narrowing down this bug) When assigning a list into an existing index, it correctly errors on incompatible type, and the expression vector is unchanged: ``` x <- expression(a,b,c) x[[3]] <- list() # Error x #>