Re: [Chicken-hackers] CHICKEN in production

[Jörg F. Wittenberger]

Am 08.10.2014 um 21:27 schrieb John Cowan:
> Peter Bex scripsit:
>
> > Thanks for speaking up, I hadn't considered how big of a problem this
> > would be for large, existing projects.  We could possibly make it a
> > runtime option, so the checking (or just the enforcing) could be enabled
> > or disabled at will.
> Here are my suggestions for staging this change.
>
> Next release of Chicken 4:
>
> Continue to allow NUL in strings (backward compatible)

+1

> Add a trailing hidden NUL to all strings (C compatible)

Given our experience with RScheme, I still believe this is a bad idea.  
You can't really get rid of that once it is in.

I don't recall anymore what the precise problem was.  Maybe I should 
talk to the buddy who actually ran into these problems.

> Eliminate copying in the FFI (big performance win)
> Continue checking for NUL in the FFI (safety)
>
> Chicken 4 with run-time option / Chicken 5 by default:
>
> Disallow NUL in strings (break backward compatibility)
> Eliminate checking for NUL in the FFI (no longer needed)
>
> How does that sound?

Since chicken 5 is already there (and I'm depending on the fixes to the 
current version to run our code at all, which forces more work to set up 
a "compile your modified chicken" build for the time being), I rather 
try porting those fixes into chicken 5, skipping the double effort.

For this I'd need to be able to run chicken 5 with no NULL checks 
against strings as those still triple as both blobs and UTF-8 strings in 
our code base.  And I can't possibly a) follow all those changes to 
chicken 5 b) find a solution to possibly wrong uses of those new strings 
in our code c) port those fixes into chicken 5.

Sorry

/Jerry