[Rd] Bug: C-level and _set_rl_word_breaks

[Laurent Gautier]

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