chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] CHICKEN in production


From: Peter Bex
Subject: Re: [Chicken-hackers] CHICKEN in production
Date: Wed, 8 Oct 2014 19:46:20 +0200
User-agent: Mutt/1.4.2.3i

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.

> > The upshot of this is that a string will need to be checked at most
> > once, and never copied (except as is done normally, by the GC).
> 
> Well, string-set! and string-fill! and the like would have to check
> for inserting NUL and either set the taint bit (if you really want
> to keep such strings available) or barf.

Correct.

Cheers,
Peter
-- 
http://www.more-magic.net



reply via email to

[Prev in Thread] Current Thread [Next in Thread]