Re: [Chicken-hackers] Made a start with CHICKEN 5 proposal

[Oleg Kolosov]

On 08/29/14 23:01, Peter Bex wrote:
> On Fri, Aug 29, 2014 at 10:50:31PM +0400, Oleg Kolosov wrote:
>> On 08/23/14 19:35, Peter Bex wrote:
>>> I've made a start on the wiki, at what we'd like CHICKEN 5 to be about.
>>
>> I've remembered one more thing: why not stick the terminating '\0' at
>> the end of all strings in internal representation? This looks pretty
>> harmless but could make some common FFI uses a breeze.
> 
> We should only do that when the \0 is rejected up front inside strings.
> Right now, \0 is allowed in a string and if you pass it to a C function,
> it is detected and an exception is raised.  Doing it with the current
> system wouldn't buy us anything, and would just make potential misuse
> more attractive, because a user would be tempted to just pass the
> string's internal buffer directly to the C API "for performance".
> This would then open up a can of worms containing plenty of potential
> vulnerabilities.

I didn't know about automatic embedded null checks for c-string - it's a
nifty feature! Will try to dig it in the sources.

It is due to fact that the c-string-list is only valid as a return type
I've ended up copying contents of scheme-object (actually passed as a
list of strings) manually in C to construct argv argument for my
"improved" process-run replacement. Also it looks like CHICKEN's own
process-execute does exactly the same. I'm not sure if the automatic
null check happens in this case.

So, following the ideas from your blog post (thanks Arthur!), I guess we
should fix c-string-list handling to allow it as an argument to let the
CHICKEN do all the checks.

I still don't see how it prevents adding the terminating null. It may
actually increase safety because users will pass raw scheme objects to C
anyway "for performance". Yes, I'm guilty, doing some embedded work as
you know. Without nulls virtually nothing prevents pointers to run
far-far away from it's intended destination in case of simple mistakes.

-- 
Regards, Oleg