Re: [Chicken-users] FFI with callbacks for gnu readline

[Levi Pearson]

On Jan 18, 2006, at 5:22 PM, Thomas Chust wrote:
> actually I doubt that the termination of strings with a '\0'  
> character is broken. Maybe the problem is rather related to garbage  
> collection somehow, if the string is used for a longer time by the  
> readline library. But nevertheless your approach here looks sensible.

I previously had scheme_completion return a c-string, and I assumed  
it would somehow generate a correctly null-terminated string.  It did  
in most cases, but occasionally there was a garbage character  
afterward.  If I did a (print) of the value I was about to return in  
scheme_completion and a printf() in completion_func() right after it  
was returned, I saw the garbage character appear between the two.  I  
don't think garbage collection could account for that.

How is returning a c-string from a define-external'd scheme function  
supposed to work?  Returning the scheme object worked fine in the  
end, but it would have been a lot easier if there was some automatic  
way.

> So just replace the foreign-lambda* by foreign-safe-lambda* in your  
> readline.scm for every function that may eventually cause a  
> callback intro Scheme and everything should be fine.

This does appear to have fixed it!  That's actually about the only  
vestige of the original readline.egg that I still have in that file.   
It worked there because there was no callback into scheme, and it  
didn't even occur to me to check there.  Thanks. :)


On Jan 18, 2006, at 7:11 PM, Zbigniew wrote:

> It looks like Thomas is right about the callback, although I can't get
> your example to crash.  I'm running Mac OS X PPC, which sometimes
> allows memory accesses that would cause segfaults elsewhere, so I have
> another possibility if you still get crashes.  Before testing for the
> scheme string length in completion_func, you do a strcmp against "".
> Here's the thing--scheme strings are never null terminated at all,
> even when returned by C_c_string (which after all just returns a
> pointer to the raw scheme data).  In fact, a NULL string will be 0
> bytes long.  This strcmp will probably access the first byte of your
> result string, which is an illegal memory access.  Instead, you should
> test that the scheme string size is 0 and return NULL if so.

I'm running Mac OS X PPC, too.  My crasher program doesn't crash  
nearly as quickly as my app does; if I hit <tab><tab><tab><return>  
repeatedly it does eventually die, though.  I think you're correct  
about the strcmp, though, so I made that change as well.  Thank you,  
too!

It's a pleasure to get prompt and informed help from a first-time  
post to a mailing list.  Hopefully things will progress much more  
smoothly now.

                --Levi