Re: [Chicken-hackers] CHICKEN in production

[Jörg F. Wittenberger]

Am 08.10.2014 um 19:46 schrieb Peter Bex:
> On Wed, Oct 08, 2014 at 11:54:06AM -0400, John Cowan wrote:
> > Peter Bex scripsit:
> > > The danger could be avoided by a taint bit: if the string is known
> > > to not contain \0, it can be passed directly.  Otherwise, it needs to
> > > be checked and marked if it's safe.  If it's unsafe, an exception can
> > > be thrown.
> > IMO the better approach is simply to forbid NUL in strings altogether.
> > It has no semantics as a character: there is never any situation in which
> > you need the NUL character as opposed to the 0 byte in a bytevector.
> > The R7RS was worded to allow implementations to do this.
> Of course you're right: this is the clean solution and would solve our
> problems with the bit representation.  The implementation would be
> nearly the same as an implementation that performs taint checking,
> but slightly simpler as it wouldn't have to correctly propagate the
> taint bit.
>
> Since we've decided to break backwards compat anyway, we can get away
> with this.  It would also clean up the distinction between string and
> blob.

While this is true, I'd like to remind you that there is a lot of code 
out there.

In this particular case I will be forced to decide my priorities: I'm 
sitting on some improvements and threading fixes and cleanups I've been 
talking about on once about a time.  Currently I'm busy documenting 
other things.  That's why you did not see patches yet. But I'd really 
love to feed them back into mainline chicken.

Breaking out the scheduler might be helpful with this.  But changing the 
meaning of strings would force me to change a huge amount of dependent 
source to even be able to merge my changes back.  That would easily 
delay these things further.

Could we refine this "forbid NUL in strings" weaken to "deprecating NUL 
in strings" until the next major version please.

This is just too much for a single change.


Thanks

/Jörg