Bug: C-level and _set_rl_word_breaks

On 2013-01-31 21:09, Duncan Murdoch wrote:

On 13-01-30 9:48 PM, Laurent Gautier wrote:

Hi,

I filed a bug report in the tracker (id #15169) a short while ago,
along with a patch, but I came back to it to see that there is
relatively little movement or participation on the tracker so I
thought I'd pitch it here (patch attached).

The function `set_rl_word_breaks` in src/unix/sys-std.c relies on
statically-allocated strings local to the function, making other C
code using the readline library, such as a program embedding
R and using readline as well, at risk of creating a segfault when
trying to free `rl_basic_word_break_characters` or
`rl_completer_word_break_characters` when changing them.

The issue was noticed when embedding R in Python (rpy2); I had an
ugly hack for a long time (less work than champion the inclusion
of a patch in R) but the iPython developers pushed what could be
demanded from the rpy2 with their "R magic" extension and
so I wrote a patch (and they have made a brittle workaround in
the meantime).

The fix would be of interest to anyone embedding R in C and using
readline (e.g., language interface developers if the language either
has a console using readline - and chances are that it does - or
an interface to readline).

The patch attached is against today's R-dev and will likely apply to
current R-2.15 branch. With the patch applied, R is building and is
passing `make check`. It could be slightly expanded by handling
cases where the calloc() or realloc() faills, although not an absolute
priority (if allocating 200 bytes fails, the system might have
bigger worries than keeping R from crashing).

I suspect the reason your bug hasn't been dealt with in the 2 weeks 
since you posted it is that you don't show any code that illustrates 
the problem it causes.  It is much easier to run some code and see 
that code that should be valid is causing a crash, than it is to 
develop code to illustrate it.

Fair enough. Now I realize that this might be a part of R codebase 
that is hardly touched; while the problem makes sense to me after 
spending time on it, a demonstrating what it causes in a minimal 
example might be best).

Easily illustrated bugs get solved before hard ones.

I guess I had a free pass since I provide a solution to the bug.

Your post here gives a lot more detail, but still no code.  This 
isn't an area I'd work on (it seems to be a Unix-only bug), but you 
might attract someone else to look at it if you include a minimal 
self-contained trigger for it.

I'll work on that.

Thanks,

L.

Duncan Murdoch