Hi, > > 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.
IMO, this is a terrible idea. At the core, the reason is simply this: If your character strings can't store NUL, your character strings can't store Unicode. And obviously, Unicode is not an end in itself, but is used by lots of other standards for the encoding of character data--none of those can be implemented in a language that can't represent Unicode (at least not using the built-in character strings--you still could reimplement your own abstraction, of course, just as you would do for sane data handling in C). Take JSON as an example: JSON character strings can encode NULs, so if CHICKEN were to reject NULs in character strings, you could not write a JSON parser in CHICKEN. Florian _______________________________________________ Chicken-hackers mailing list Chicken-hackers@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-hackers
